New iteration over the ev++ improvement patch.

Leandro Lucarella llucax at
Sat Jan 19 21:15:58 CET 2008

Marc Lehmann, el 19 de enero a las 11:55 me escribiste:
> On Fri, Jan 18, 2008 at 05:09:15PM -0200, Leandro Lucarella <llucax at> wrote:
> > About this. What about exposing the default loop functions in the ev
> > namespace?
> thats probably not a bad idea, as it underscores that the default loop is not
> an objetc to be instantiated by user code.
> to me, ev::init doesn't give me the default loop or intziailises, it simply
> ensures that the default loop is there.
> and ev::destroy is more a "really, destroy it even if everybody else hates
> it, because for some obscure reason we should not have a default loop" (i
> cannot imagine such situation, really, I am open for examples).
> > ev::init (flags) -> ev_default_loop (flags)
>   ev::default_loop or default_init (not that important)
> > ev::get ()       -> ev_default_loop (0)
>   maybe ev::default_loop () as well?

I just like to separate initialization from just getting a pointer/object.
But I can understand the C API don't do that so the C++ API shouldn't

> > ev::count ()     -> ev_count (ev_default_loop (0))
> > ev::backend ()   -> ev_backend (ev_default_loop (0))
> > 
> > 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:
> How about nuking th default_loop wrapper and instead returnign a loop_ref of
> the default loop instead?
> Then the interface would be the same:
>    ev::default_loop ().loop ()
>    ev::default_loop ().post_fork ();
> etc. I think default_loop should preferably a variable (this has many
> problems! don't! :)

I would say to make a macro:
#define loop default_loop ()
but they don't go too well with namespaces :S

> that is, have functions only for the most common uses (such as loop) and
> stuff you can't have in a loop_ref (create/destroy), but keep everythign else
> in the loop_ref.
> > void cb (watcher &w, int revents)
> > {
> > 	w.loop.unloop (); // I don't care if is the default or not.
> > }
> That should definitely work, yes.
> > So you can reuse callbacks. You can also use automatic destruction for the
> > default loop:
> automatic destruction for the default loop makes what sense? I'd really
> like to know. In about 100% of the cases its a big waste of time and
> resources.

Mmm, I like at least to avoid valgrind complaining about memory loss,
which I had with libevent (but that's a different story because it doesn't
split the loop in a default and multiple dynamic), but I'm looking the
valgrind output for a trivial example and there is only still reachable
memory. The weird thing is that when calling ev_default_destroy (), I
get a lot of errors about 0 bytes in 1 blocks are definitely lost. When
I don't call ev_default_destroy () there is more memory still reachable,
but no errors about 0 bytes lost :S.

> > PS: The "big" problem comes with ev::now () =P
> hhehe, my proposal fixes thta, as it would be:
> ev::default_loop ().now ()
> i think users should store the default_loop in soem variable as soon
> as possible anyways (and most people will liekly do just to avoid the
> function call).

I'm not a fan of inconsistencies, as you said, if not all default loop
methods are provided as free functions, then you'll have to remember which
are available and which are not.

So if you think most people will have the loop in a local variable I'll
leave the things are they are now (except, maybe for the default_loop
nuking and making default_loop () to return a loop_ref for the default

So, what about just making the changes in this patch?;a=commitdiff;h=fcd0395b31f47157bd7e2929a3c375c24944cbc8

Leandro Lucarella (luca) | Blog colectivo:
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
Soñé que tenia un caballo
Que me trataba mejor que vos
Tenia tan buena onda con ella
Era mi yegua, mucho mas que vos

More information about the libev mailing list