Making Async play better with others
Yaron Minsky
yminsky at janestreet.com
Thu Nov 3 01:44:17 GMT 2011
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
More information about the core
mailing list