Hi Cedrik, thanks for sharing your findings.
On 2023-06-29 16:44, ttco...@netcourrier.com wrote:
* vfs_pipe: components that use the "pipe" plug-in should make sure to enable RTC (<libc rtc="/dev/rtc"...>) as of 23.02 -- previously it would work without specifying an RTC path. This probably has zero impact since everyone properly configures their libc config (unlike me in the one scenario that brought this up..!)
This made me curios because the nightly tests [1,2] for the vfs_pipe plugin do in fact not configure the rtc for the libc, yet are known to work.
[1] https://github.com/genodelabs/genode/blob/master/repos/libports/recipes/pkg/test-libc_fifo_pipe/runtime [2] https://github.com/genodelabs/genode/blob/master/repos/libports/recipes/pkg/test-libc_pipe/runtime
I guess that the use of the rtc has a side effect that covers up the symptom of a problem that might still lurk there. To get to the bottom of it, I'd need more information or - ideally - a scenario to reproduce the non-working state.
There is one suspicion: The VFS changes in 23.02 foster the batching of I/O in the file-system session. When operating both sides of a pipe through the same file-system session, there is the risk that a write operations fits into the file-system session's packet-stream buffer but not in the pipe buffer in the remote pipe. Once the pipe is saturated, a reader must consume content before any new progress can be made. But when the reader issues its read request through the same file-system session as used by the writer - which is still clogged by the not yet completed write operation - we end up in a deadlock situation. May this be the case in your scenario?
In practice, such situations don't occur whenever both ends of one pipe are operated by different components - each using a distinct file-system session. But when interacting with a pipe behind a chain of VFS servers, stalling effects are plausible. But as I said, I'm just speculating.
Should you by any chance find a way to come up with a run script that shows the non-working behavior, I'd love to investigate it.
Cheers 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 _______________________________________________ Genode users mailing list users@lists.genode.org https://lists.genode.org/listinfo/users
