I'm currently debugging a problem where the man tool gets stuck on Genode and it seems to be related to non-blocking pipes in combination with the vfs server.
The test case in commit cproc/genode@a5527c8 tries two times to write up to 128K bytes non-blocking into a pipe and then to read up to 128K non-blocking from the pipe.
On Linux and FreeBSD the log output looks like this:
writing up to 131072 bytes
wrote 65536 bytes (buffered: 65536)
reading up to 131072 bytes
read 65536 bytes (buffered: 0)
writing up to 131072 bytes
wrote 65536 bytes (buffered: 65536)
reading up to 131072 bytes
read 65536 bytes (buffered: 0)
64K could be written and read each time.
On Genode, with a local vfs_pipe plugin, the log output looks like this:
[init -> test -> libc_pipe_local] writing up to 131072 bytes
[init -> test -> libc_pipe_local] wrote 8192 bytes (buffered: 8192)
[init -> test -> libc_pipe_local] reading up to 131072 bytes
[init -> test -> libc_pipe_local] read 8192 bytes (buffered: 0)
[init -> test -> libc_pipe_local] writing up to 131072 bytes
[init -> test -> libc_pipe_local] wrote 8192 bytes (buffered: 8192)
[init -> test -> libc_pipe_local] reading up to 131072 bytes
[init -> test -> libc_pipe_local] read 8192 bytes (buffered: 0)
[init -> test] child "libc_pipe_local" exited with exit value 0
8K could be written and read each time.
With the vfs_pipe plugin in a vfs server the log output looks like this:
[init -> test -> libc_pipe_remote] writing up to 131072 bytes
[init -> test -> libc_pipe_remote] wrote 63968 bytes (buffered: 63968)
[init -> test -> libc_pipe_remote] reading up to 131072 bytes
[init -> test -> libc_pipe_remote] read -1 bytes (buffered: 63968)
[init -> test -> libc_pipe_remote] writing up to 131072 bytes
[init -> test -> libc_pipe_remote] wrote 63968 bytes (buffered: 127936)
[init -> test -> libc_pipe_remote] reading up to 131072 bytes
Error: Test execution timed out
In this case, more data than fits into the pipe was accepted to be written, the first read attempt got errno EAGAIN and the second read attempt blocked. With some instrumentation of the vfs server it looks like the first write job is being processed (but could not write that much data into the pipe), then a "read-ready" job was processed as "ready", then the second write job is considered not acceptable because the first write job is not finished yet and the read job is not processed as well.
I'm currently debugging a problem where the
mantool gets stuck on Genode and it seems to be related to non-blocking pipes in combination with the vfs server.The test case in commit cproc/genode@a5527c8 tries two times to write up to 128K bytes non-blocking into a pipe and then to read up to 128K non-blocking from the pipe.
On Linux and FreeBSD the log output looks like this:
64K could be written and read each time.
On Genode, with a local
vfs_pipeplugin, the log output looks like this:8K could be written and read each time.
With the
vfs_pipeplugin in a vfs server the log output looks like this:In this case, more data than fits into the pipe was accepted to be written, the first read attempt got errno
EAGAINand the second read attempt blocked. With some instrumentation of the vfs server it looks like the first write job is being processed (but could not write that much data into the pipe), then a "read-ready" job was processed as "ready", then the second write job is considered not acceptable because the first write job is not finished yet and the read job is not processed as well.