lib/stream.c:varlink_stream_bridge() switches the client/server sockets to non-blocking mode. At least the write() call should handle the non-fatal errno codes EAGAIN, EWOULDBLOCK and EINTR from write(). Otherwise silent data loss occurs.
Ideally the read() code does the same, so it doesn't need to re-enter the function to keep bridging data.
I've noticed this issue during a manual audit for these specific problems as we evaluate varlink as our next-gen IPC. We have painful experience with non-blocking sockets for 19+ years ;) We'll probably extend varlink for our use with netstring encapsulation during transport in a backward-compatible way as JSON data always starts with '{' or '['.
lib/stream.c:varlink_stream_bridge() switches the client/server sockets to non-blocking mode. At least the write() call should handle the non-fatal errno codes EAGAIN, EWOULDBLOCK and EINTR from write(). Otherwise silent data loss occurs.
Ideally the read() code does the same, so it doesn't need to re-enter the function to keep bridging data.
I've noticed this issue during a manual audit for these specific problems as we evaluate varlink as our next-gen IPC. We have painful experience with non-blocking sockets for 19+ years ;) We'll probably extend varlink for our use with netstring encapsulation during transport in a backward-compatible way as JSON data always starts with '{' or '['.