PATCH: Integrating libev with other runloops

Marc Lehmann schmorp at
Sun Oct 24 13:54:51 CEST 2010

On Sat, Oct 23, 2010 at 06:36:13PM +0200, Rasmus Andersson <rasmus at> wrote:
> systems already use a runloop system of their own (e.g. OS X
> applications use something called CFRunLoop) thus there's a need to
> have node running in symbios with these systems.

This can already be done without any changes, and more portably and
efficiently, btw.

There are also a number of bugs in your approach:

> • ev_backend_fd -- ability to acquire the FD used by the backend (e.g.
> to register for events so the parent runloop can yield for libev when
> appropriate).

there is no fd in most cases, and even if, it might not be pollable (see
epoll for example).

> • ev_refcount -- ability to know the number of active events, so the
> runloop iteration invocation can be optimized.

ev_refcount won't tell you the numbe rof active events.

> • ev_loop_fdchangecount -- ability to know when to stop yielding for libev

fdchangecount is an internal variable, and has nothing to do with the number
of pending watchers, which is what you really need to know.

> • ev_loop_next_waittime -- ability to know when to next invoke ev_loop.

Likewise here, this time doesn't tell you when to invoke ev_loop at all.

I don't think going into the direction you wish has any future, its too
hacky even if you fix the obvious bugs - using e.g. a thread would not
require any hackery and would actually work reliable.

> Would really appreciate this patch being integrated!

I don't think this functionality is sane - the information you expose is
internal and doesn't provide the information you wish to have.

                The choice of a       Deliantra, the free code+content MORPG
      -----==-     _GNU_    
      ----==-- _       generation
      ---==---(_)__  __ ____  __      Marc Lehmann
      --==---/ / _ \/ // /\ \/ /      schmorp at
      -=====/_/_//_/\_,_/ /_/\_\

More information about the libev mailing list