Is it safe to call uv_close on send_handle in the uv_write2 callback?

[Cesar Blum]

In the Kestrel HTTP server (https://github.com/aspnet/KestrelHttpServer) we have multiple threads servicing client connections. In order to use uv_handle_t's with multiple threads, what we've done is to have a primary thread listen to new connections and dispatch them to secondary threads by sending the accepted uv_stream_t's over pipes.

We've been observing some issues only on OS X where our secondary threads' read callbacks immediately get UV_EOF's when data was expected to arrive (we can actually see the data in the network using tcpdump).

Right now, our logic in the primary thread is basically:

- Accept new connection

- Select a secondary thread to dispatch to.

- uv_write2 the accepted uv_stream_t to the secondary thread's pipe.

- In the callback to uv_write2, call uv_close on the uv_stream_t we just sent over to the secondary thread.

I was able to mitigate those issues by delaying the call to uv_close to only after the secondary thread has accepted the uv_stream_t sent to it. I did this by waiting for an "ack" on the pipe over which the uv_stream_t was sent and then dispose it (the uv_stream_t) in the primary thread.

Is this how we're supposed to close the accepted uv_stream_t in the primary thread? We don't see the same issue on other operating systems. But it seems like OS X ends up with a stream in an invalid state if the original descriptor is closed before it is accepted at the other end of the pipe connection. It doesn't signal any errors in this situation and just returns EOF on any attempt to read the stream.

--

Cesar Blum

[Ben Noordhuis]

It should be safe to close the handle in your uv_write2 callback, by
that time the file descriptor has been handed off. Can you file a bug
report, preferably with a test case or steps to reproduce? Thanks.