Also, this guarantee isn't very useful in context of coroutines. I.e. it guarantees that related couroutine(s) will resume before close_cb is called, but it won't guarantee that it will complete execution (and not suspend again). I.e. if your write/read/connect callback is used to resume a coroutine -- you probably better off adding explicit synchronization between your coroutine execution and related data structure destruction.
On Mar 27, 2018 9:39 PM, "Michael Kilburn" <[email protected]> wrote: > On Sun, Mar 25, 2018 at 8:26 PM, Michael Kilburn <[email protected]> > wrote: > >> On Sun, Mar 25, 2018 at 2:05 PM, Jameson Nash <[email protected]> wrote: >> >>> > unless uv_close() keeps track of currently outstanding requests and >>> Libuv keeps track of all outstanding requests (how else would it have >>> known who to notify for completion) >>> >> >> So, can I rely on uv_close callback to be invoked after all outstanding >> requests (on handle being closed) are canceled (and their callbacks are >> invoked)? >> > > For future reference: > I spent considerable time looking through uv_close() code for uv_tcp_t > (win and linux) -- it seems that (as of now) close_cb is guaranteed to be > called after all outstanding connect_cb/write_cb/read_cb are invoked with > UV_ECANCELED. I am about 95% sure -- some of code paths I looked at are > mind-bending... > > It also seems that considerable effort was made to deliver this behavior > (esp in Windows case) -- i.e. there is a good chance this guarantee is > intentional and will stand. > > Still not sure about other handle types (and general intent wrt order of > close_cb invokation and UV_ECANCELED delivery). > > > -- 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 https://groups.google.com/group/libuv. For more options, visit https://groups.google.com/d/optout.
