On Fri, Feb 15, 2008 at 6:18 PM, Eric Brown <[EMAIL PROTECTED]> wrote:
> My suggestion, however, would be to consider adding a layer on top of your > thin API for the open-source Eventlet stuff secondlife is developing -- > http://wiki.secondlife.com/wiki/Eventlet. The co-routines provided there > remove the need to think about callbacks all the time. That is, the state is > stored in the stack of a given co-routine (eventlet). > That's uncannily close to what I ended up building on top of libev in Ruby: http://revactor.org/ However I modeled the actual architecture after Erlang. Revactor also uses coroutines (i.e. Ruby Fibers) to make non-blocking I/O operations appear blocking at the source code level, eliminating the inversion-of-control problems in Reactor-like APIs. However, it also provides Erlang-like "active mode" semantics for problems which are well suited to asynchronous programming, like message processing. That said, the first thing I wrote was a lightweight wrapper to libev (Rev), and a Reactor-like framework on top of it. I'd certainly suggest starting there. > I only wish there was a mainstream co-routine library for gcc/g++. > Ever look at libpcl? http://www.xmailserver.org/libpcl.html -- Tony Arcieri ClickCaster, Inc. [EMAIL PROTECTED]
_______________________________________________ libev mailing list [email protected] http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
