Callbacks Question

Matt Tolton matt at tolton.com
Tue Jan 1 20:07:59 CET 2008


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 <schmorp at schmorp.de> wrote:
> On Mon, Dec 31, 2007 at 04:45:06PM -0700, Matt Tolton <matt at tolton.com> 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
>       --==---/ / _ \/ // /\ \/ /      pcg at goof.com
>       -=====/_/_//_/\_,_/ /_/\_\
>



More information about the libev mailing list