Hi Stefan, > There are good reasons to implement an application with non-blocking > write and use select. The most common is not complicating the code with > thread synchronization. > >> In short, our design tries the leverage async I/O for hiding the latency >> of write operations, and it yields the desired behavior of blocking >> instead of busylooping when no progress can be made. > > As far as I understand, this leads to a blocking write when all buffers > are full even when the application intended a non-blocking write. I'm > not convinced this is a good solution for best compatibility for porting > posix/libc applications.
Please don't mistake my statement as an argument against non-blocking writes. I'm with you. My explanation referred to the file-system session level because you questioned the design of the file-system session. At the libc level, there is of course the distinction between blocking and non-blocking writes (see [1]) in place. [1] https://github.com/genodelabs/genode/blob/master/repos/libports/src/lib/libc/vfs_plugin.cc#L829 > Also, when the write fails for another reason, such as a lack of disk > space the application can't detect that problem and data may be lost. This would be modeled as an I/O error, which can indeed be propagated via the acknowledgement of a write operation today. To avoid data loss under such circumstances, the condition of a full disk could be propagated as an I/O error in advance of the catastrophic condition, when reaching a certain disk-usage threshold. The file system could asynchronously report the error via a write-acknowledgement while still successfully completing the pending requests. Currently, such situations would trigger a diagnostic message only. However, we consider flagging the corresponding libc FD when observing this condition. This way, a subsequent attempt to use the file descriptor would return an error. That said, this mechanism is not implemented as of now. But the design holds. > You are of course correct, the vfs component doesn't block but retries > the same write later with not success. Read from another session works > just fine and lets the write succeed. That's good. Thank you for reporting back. Regards Norman -- Dr.-Ing. Norman Feske Genode Labs https://www.genode-labs.com · https://genode.org Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Genode users mailing list [email protected] https://lists.genode.org/listinfo/users
