PATCH: Integrating libev with other runloops
Rasmus Andersson
rasmus at notion.se
Sun Oct 24 16:31:59 CEST 2010
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
More information about the libev
mailing list