PATCH: Integrating libev with other runloops

[Rasmus Andersson]

On Sun, Oct 24, 2010 at 15:56, Marc Lehmann <schmorp at schmorp.de> wrote:
> 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).

I want to avoid all hurdles with locking and message passing imposed
by a separate thread. In our case, nodejs drives many parts of the OS
X application and parts of the OS X (C-land) app manipulates things
within nodejs. The first implementation was actually based on nodejs
running in a separate thread, but turned out to be too cumbersome and
cause problems.

IMHO driving one runloop with another is a "clean" solution and the way to go.

>
>> 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 the case of nodejs the program exits in two cases: either when
explicitly terminated (unroll all or exit syscall) OR when no more
watchers are registered (more correctly, when the runloop reference
count drops to 0).

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

Ah, so if ev_run returns 0 that means I can mark the libev runloop as
"unrolled"? And this will include ev_ref/ev_unref's?

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

The implementation in my patch, and thus used in our code, is simply
copy-pasted from the ev_run code, where AFAIK approximation of next
invocation is calculated. How would this be solved using the current
libev (4.0) API in your opinion?

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

OK, I'll investigate further.

Thank you.

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



-- 
Rasmus Andersson