On Sun, Oct 24, 2010 at 15:56, Marc Lehmann <[email protected]> wrote: > On Sun, Oct 24, 2010 at 02:48:29PM +0200, Rasmus Andersson <[email protected]> > 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 > --==---/ / _ \/ // /\ \/ / [email protected] > -=====/_/_//_/\_,_/ /_/\_\ > -- Rasmus Andersson _______________________________________________ libev mailing list [email protected] http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
