Thanks for the reply. Is this intentional design choice? In absence of a read callback what's the typical/recommended way for an application to clean up resources when the read is - in effect - cancelled by uv_close()? For example, in my application I have a coroutine suspended after calling uv_read_start() that will be resumed from on_read_cb(). I also start a timer for readTimeout milliseconds which if invoked calls uv_close() on the same socket to implement read time out functionality. Now my problem is my original coroutine never gets resumed in this case because uv_close() doesn't cause on_read_cb() to be invoked at all. In a parallel use case involving connect() and connect timeout implementation everything works perfectly as uv_close() causes on_connect_cb() to be called with UV_ ECANCEL. Shouldn't read() behave similarly?
Thanks, - Susheel > If the socket was connected you'll get the read callback called with > UV_EOF, > > but not if it was never connected. > > > Mmm, that is not true. If you call uv_close(), even on a connected TCP > handle, it does not fire a uv_read_cb with UV_EOF at all (that only > happens if the peer closes its side of the TCP connection). > > > -- > Iñaki Baz Castillo > <[email protected] <javascript:>> > -- 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.
