2014-04-21 8:36 GMT+02:00 Susheel Aroskar <[email protected]>: > 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?
uv_connect_cb takes a uv_req_t so it can be cancelled. uv_read_start() does not take a uv_req_t so it cannot. Your application should react on the uv_close_cb (after you have called to uv_close()) and free resources there and just there. -- Iñaki Baz Castillo <[email protected]> -- 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.
