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