PATCH: Integrating libev with other runloops

[Rasmus Andersson]

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:

~~BEGIN~~

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

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

while (ev_refcount(EV_DEFAULT_UC) && gTerminationState != 2) {
  NSAutoreleasePool* pool = [NSAutoreleasePool new];
  ev_run(EV_DEFAULT_UC_ EVLOOP_NONBLOCK);
  double next_waittime = ev_loop_next_waittime(EV_DEFAULT_UC);
  NSDate* next_date = [NSDate dateWithTimeIntervalSinceNow:next_waittime];
  NSEvent* event = [NSApp nextEventMatchingMask:NSAnyEventMask
                          untilDate:next_date
                          inMode:NSDefaultRunLoopMode
                          dequeue:YES];
  [NSApp sendEvent:event];
  [pool drain];
}

~~END~~

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
FD)?


Thanks!

On Sun, Oct 24, 2010 at 13:56, Marc Lehmann <schmorp at schmorp.de> wrote:
> On Sat, Oct 23, 2010 at 11:55:30PM -0000, Christian Parpart <trapni at gentoo.org> 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_              http://www.deliantra.net
>      ----==-- _       generation
>      ---==---(_)__  __ ____  __      Marc Lehmann
>      --==---/ / _ \/ // /\ \/ /      schmorp at schmorp.de
>      -=====/_/_//_/\_,_/ /_/\_\
>
> _______________________________________________
> libev mailing list
> libev at lists.schmorp.de
> http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
>



-- 
Rasmus Andersson