vfs fifo pipe and file system session write

Norman Feske norman.feske at genode-labs.com
Wed Dec 9 18:00:20 CET 2020

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.


> 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.


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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.genode.org/pipermail/users/attachments/20201209/a36ee02b/attachment-0001.sig>

More information about the users mailing list