Hi Marc, > I don't understand the reasoning. A watcher can be pending within its own > callback (because it can become pending while executing the callback, e.g. > when recursing into ev_loop).
Ok. I didn't think about this situation. Why would you want to recurse into ev_loop? Are there any other ways besides recursing into ev_loop that might put it into the pending state? > if you do "interesting" stuff in your callback and are not sure wether you > recurse again into the event loop or so, the safe route is to always call > ev_xxx_stop first, but this is unliekly to be necessary. What counts as "interesting" stuff? What calls into libev do I need to be aware of that might recurse (aside from calling ev_loop again)? Thanks for your time. Matt On 1/1/08, Marc Lehmann <[EMAIL PROTECTED]> wrote: > On Mon, Dec 31, 2007 at 04:45:06PM -0700, Matt Tolton <[EMAIL PROTECTED]> > wrote: > > >From what I can determine, it should not be possible for a watcher to > > be pending within its callback. This should mean that if I stop the > > watcher, it will be ok to free the memory associated with it. > > > > I'd like to verify that the above is true...is it? > > I don't understand the reasoning. A watcher can be pending within its own > callback (because it can become pending while executing the callback, e.g. > when recursing into ev_loop). > > stopping, however, will be clearing the pending state, so you can indeed > free its memory after calling stop (even when the watcher already *is* > stopped, ev_xxx_stop will clear any pending state). > > if you make sure in your callback that: > > a) the watcher is stopped (e.g. because it was a one-shot timer or > you called ev_xxx_sotp) > b) it did not become pending again (e.g. by avoiding calls to ev_loop > or submittign events) > > then you can safely free the weatcher memory, it will no longer be accessed > by libev afterwards. > > if you do "interesting" stuff in your callback and are not sure wether you > recurse again into the event loop or so, the safe route is to always call > ev_xxx_stop first, but this is unliekly to be necessary. > > -- > The choice of a Deliantra, the free code+content MORPG > -----==- _GNU_ http://www.deliantra.net > ----==-- _ generation > ---==---(_)__ __ ____ __ Marc Lehmann > --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] > -=====/_/_//_/\_,_/ /_/\_\ > _______________________________________________ libev mailing list [email protected] http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
