New iteration over the ev++ improvement patch.

Leandro Lucarella llucax at
Fri Jan 18 20:09:15 CET 2008

Marc Lehmann, el 18 de enero a las 06:08 me escribiste:
> > * A new function ev::get_default_loop () is provided to get a loop_ref to
> >   the default loop. Once again, no check is done to ensure this function
> >   wont get called before actually creating the default loop.
> Can't help it, I still am not sure we should provide an actual default
> loop wrapper, as I think the default loop is a shared resource that is not
> controlled by any one instance.

About this. What about exposing the default loop functions in the ev

ev::init (flags) -> ev_default_loop (flags)
ev::get ()       -> ev_default_loop (0)
ev::loop (flags) -> ev_loop (ev_default_loop (0), flags)
ev::unloop (how) -> ev_unloop (ev_default_loop (0), how)
ev::post_fork () -> ev_default_fork ()
ev::destroy ()   -> ev_default_destroy ()
ev::count ()     -> ev_count (ev_default_loop (0))
ev::backend ()   -> ev_backend (ev_default_loop (0))
etc., etc., etc.

I'll keep the default loop struct wrapper too, because in a multi loop
environment let you use a callback for a default or a dynamic loop
indisticly, like:

void cb (watcher &w, int revents)
	w.loop.unloop (); // I don't care if is the default or not.

So you can reuse callbacks. You can also use automatic destruction for the
default loop:

	ev::default_loop l;
	// ...
	// bye, bye, l gets destroyed

But you can avoid it:
ev::init ();
ev::loop ();

And you have more concise way to use the omnipresent default loop, like
you can do something like:
ev::count ();
instead the longer:
ev::get_default_loop ().count ();

The struct wrapper could be avoided for EV_MULTIPLICITY=0 too.

What do you think?

PS: The "big" problem comes with ev::now () =P

Leandro Lucarella (luca) | Blog colectivo:
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
	-- Crónica TV

More information about the libev mailing list