Making Async play better with others

[Yaron Minsky]

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.

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

y


-- 
Yaron Minsky