PATCH: Integrating libev with other runloops

[Marc Lehmann]

On Sun, Oct 24, 2010 at 02:48:29PM +0200, Rasmus Andersson <rasmus at notion.se> wrote:
> 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.

You can simply run it in another thread for example (the thread locking
example in the documentation shows how).

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

The question of when to exit is not something libev or the event lop can
answre, only your application knows when to exit or not. A specific
application can tie it to the refcount, but thats app-specific.

In any case, you know there are no active watchers anymore when ev_run
returns.

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

This is broken by design - ev_run polls for new events, and if you call
ev_run only from time to time you will delay event notification by this
amount.

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

Not sure what you mean, but not all backends have an fd, and not all
who do work in the way you would need it. Libev tells you that it is
ready to poll (and the kernel state is updated) when it calls the release
callback - no need to expose an internal number that might or might not be
relevant, depending on the backend.

-- 
                The choice of a       Deliantra, the free code+content MORPG
      -----==-     _GNU_              http://www.deliantra.net
      ----==-- _       generation
      ---==---(_)__  __ ____  __      Marc Lehmann
      --==---/ / _ \/ // /\ \/ /      schmorp at schmorp.de
      -=====/_/_//_/\_,_/ /_/\_\