Making Async play better with others
Anil Madhavapeddy
anil at recoil.org
Fri Nov 4 09:41:47 GMT 2011
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
More information about the core
mailing list