PATCH: Integrating libev with other runloops

Rasmus Andersson rasmus at
Sun Oct 24 14:48:29 CEST 2010

I'm definitely interested in a clean and non-hacky approach, but AFAIK
it's simply impossible with the current libev API when integrating
with a OS X application runloop.

This is a condensed version of the OS X app runloop driver:


static void KqueueCallback(CFFileDescriptorRef backendFile,
                           CFOptionFlags callBackTypes,
                           void* info) {
  CFFileDescriptorEnableCallBacks(backendFile, kCFFileDescriptorReadCallBack);

CFRunLoopSourceRef backendRunLoopSource =
      CFFileDescriptorCreateRunLoopSource(NULL, ev_backend_fd(), 0);
CFRunLoopAddSource(CFRunLoopGetCurrent(), backendRunLoopSource,
CFFileDescriptorEnableCallBacks(backendFile, kCFFileDescriptorReadCallBack);

while (ev_refcount(EV_DEFAULT_UC) && gTerminationState != 2) {
  NSAutoreleasePool* pool = [NSAutoreleasePool new];
  double next_waittime = ev_loop_next_waittime(EV_DEFAULT_UC);
  NSDate* next_date = [NSDate dateWithTimeIntervalSinceNow:next_waittime];
  NSEvent* event = [NSApp nextEventMatchingMask:NSAnyEventMask
  [NSApp sendEvent:event];
  [pool drain];


1. If I simply let the runloop continue forever (i.e. not checking
refcount) how will I know when to exit?

2. If I don't know when the next timer event is scheduled to happen
(i.e. not using ev_loop_next_waittime), how will I know for how long
to wait until retrying ev_run again?

3. Can I live without helping libev poll when the kernel has one or
more reads pending (i.e. not registering for events on the backend


On Sun, Oct 24, 2010 at 13:56, Marc Lehmann <schmorp at> wrote:
> On Sat, Oct 23, 2010 at 11:55:30PM -0000, Christian Parpart <trapni at> wrote:
>> But if libev officially supports integrating into other event loops (or
>> vice versa) then I'd highly appreciate it. :-)
> libev supported this officially from the very beginning, in many ways
> (each event loop is different of course, and support is required by both
> embedding and embedded loop) - the fatc that there are both solutions to
> embed glib in libev and vice versa shows this.
> it does need to be implemented cleanly however - exposing some unrelated
> internal values is not going to work reliably.
> --
>                The choice of a       Deliantra, the free code+content MORPG
>      -----==-     _GNU_    
>      ----==-- _       generation
>      ---==---(_)__  __ ____  __      Marc Lehmann
>      --==---/ / _ \/ // /\ \/ /      schmorp at
>      -=====/_/_//_/\_,_/ /_/\_\
> _______________________________________________
> libev mailing list
> libev at

Rasmus Andersson

More information about the libev mailing list