Hi, I've been following a guide explaining how to send TCP sockets over pipes found at https://nikhilm.github.io/uvbook/processes.html#sending-file-descriptors-over-pipes.
I've noticed on mac and linux that if I send a 1 byte "dummy_buf" using uv_write2 and I return a 1 byte buffer from the workers' alloc_buffer callback, the workers' on_new_connection callback will sometimes be called with nread == 0. In these circumstances (and only these circumstances in my testing at least) uv_pipe_pending_count will return 0. On windows nread is never zero and uv_pipe_pending_count never returns zero. I've also noticed if I return a 2 byte buffer from the alloc_buffer callback, I never see nread == 0 or uv_pipe_pending_count return 0 even on mac and linux. Sadly, having the alloc_buffer callback return a larger than necessary buffer causes an issue on windows where part of the *next* ipc frame to be read into the to returned buffer under high load. This, of course, turns into complete disaster where the following assertion fails: https://github.com/libuv/libuv/blob/2a51b61e460b43b6813425c239db1e5db6931fc9/src/win/pipe.c#L1633 and the pipe rendered unusable. This can all be worked around by simply using the same sized buffers on both the sending and receiving side and then accepting that nread/uv_pipe_pending_count will sometimes equal zero on mac/linux in which case I just immediately exit the callback. I just want to make sure this is the expected behavior, and that this is the right thing to do. If this isn't expected, I'm happy to file an issue. Thanks for reading, Stephen -- You received this message because you are subscribed to the Google Groups "libuv" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/libuv. For more options, visit https://groups.google.com/d/optout.
