Making Async play better with others

[Anil Madhavapeddy]

On Wed, Nov 02, 2011 at 09:44:17PM -0400, Yaron Minsky wrote:
> On 02/11/11 22:24, Anil Madhavapeddy wrote:
> > A pluggable engine will give you the lowest common denominator
> > and/or a poorly tested set of alternatives (most users will just one
> > the default one). There are observable differences between the
> > backends (e.g. select returns immediately if you pass in a block
> > device fd, whereas epoll can often wedge forever and never return).
> > 
> > The reason I like libuv is because its most aligned with the Core
> > "full service" feature set, whereas the rest are mostly just network
> > I/O.  Node.js is very similar in terms of its runtime architecture
> > to Core+Async (C non-blocking runtime, language VM activations).
> > Letting that community deal with platform portability would save a
> > lot of time.
> >  
> > I've written servers in both libevent and libev, and they are both
> > pretty good for network AIO. The scalability differences between
> > them won't matter for 99% of users.
> 
> That's not a crazy idea.  As I said, it's a little hard to imagine
> that we'd want to run our own apps through libuv, but I could imagine
> it as an alternate backend.

Yeah, two backends would work if they both have users (Jane Street for the
direct one, and the "community" for the libuv one). I imagine they would
converge as confidence grows (or not) in one or the other.

> I agree that a general-purpose pluggable engine sounds like it would
> cause trouble.  But maybe we can get to supporting two backends.

Agreed. It would certainly make the various *BSD and Windows ports much
more tractable.

-- 
Anil Madhavapeddy                                 http://anil.recoil.org