Ok. Thanks. On Monday, April 21, 2014 3:02:40 AM UTC-7, Iñaki Baz Castillo wrote: > > 2014-04-21 8:36 GMT+02:00 Susheel Aroskar > <[email protected]<javascript:>>: > > > 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] <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.
