Making Async play better with others

[Yaron Minsky]

I agree that you want to use one of those libraries if you're programming
against epoll and kqueue.  I'm less sure that you should use them in
preference to select (which, from both some experiments I think Markus
Mottl ran, and other things I've heard is faster for moderate numbers of
file descriptors) is less clear.

But even once you agree you need one of these libraries, it's till not
clear to me how to pick amongst libev, libuv and libevent.  libevent seems
like the most mature, libev is claimed (by the author anyway) to be more
efficient, and libuv seems to treat Windows as a first-class citizen.  This
is to some degree why I like the idea of a pluggable engine, which would
prevent us from needing to commit to a single answer.

y

On Tue, Nov 1, 2011 at 6:24 AM, Dmitry Astapov <dastapov at gmail.com> wrote:

> I read quite a lot about libev, which seems to be an ancestor of libuv
> while I hunted for bugs in the code which had direct bindings for
> epoll and kqueue. And in my experience, libev handles so many bugs and
> quirky situations in underlying polling mechanisms that one must be
> really, really condfident that he is rejecting libev (or any other
> wrapper) for a good reason (that is, that he would do the same job
> better).
>
> Just search for EVBACKEND_EPOLL and EVBACKEND_KQUEUE here
> http://pod.tst.eu/http://cvs.schmorp.de/libev/ev.pod and then look at
> the relevant parts of ev_epoll.c or ev_kqueue.c and think if you want
> to have a walk through this particular minefield :)
>
> On Oct 31, 3:06 pm, Yaron Minsky <ymin... at janestreet.com> wrote:
> > On 31/10/11 14:29, Anil Madhavapeddy wrote:
> >
> > > You could combine most of these by basing Async on top of libuv,
> > > which is a superset of libev (the event library that Lwt uses to
> > > abstract network I/O).
> >
> > >https://github.com/joyent/libuv
> >
> > > Crucially, libuv has good support for the Windows AIO model, and is
> > > also what node.js uses to drive its event loop (so has widespread
> > > usage).
> >
> > > At first glance at Core, it looks like many of the Linux-specific
> > > bits like high-res timers and thread scheduling are also covered by
> > > it.
> >
> > How much do you know about the performance and quality of libuv?  I'm
> > always nervous about shimming yet another layer between us and the
> > bare metal.
> >
> > y
> >
> >
> >
> > > Anil
> >
> > > On 31 Oct 2011, at 14:25, Yaron Minsky wrote:
> >
> > > > I'm wondering if anyone has opinions on what we should do to make
> > > > Async more widely applicable.  Here are some issues that jump to
> mind.
> >
> > > > - Porting to windows.  People have proposed using libuv to do that.
> > > > - Porting to non-Linux UNIX's: Right now, we depend on Core's
> > > >  Linux_ext module.  I think the dependency is not deep, so
> > > >  conditional compilation might be a way to fix that.
> > > > - Support for other polling mechanisms: like epoll and friends.
>  Right
> > > >  now, it's all select.  A pluggable engine mechanism like the one Lwt
> > > >  has could make sense here.
> > > > - Interoperability with Lwt:  It would be nice to make Async and Lwt
> > > >  libraries play together.  Jeremie Dimino suggested that the best
> > > >  thing here might be to build a library for Lwt on top of Async.
> > > >  That seems plausible enough, but an engine in the other direction
> > > >  might be good too.
> >
> > > > I'm curious if people have opinions as to how to best handle these.
> > > > I'm in particular wondering about conditional compilation as a
> > > > solution.  It seems messy, but I'm not sure what would be a better
> > > > approach.  One thing you could imagine is using first-class modules,
> > > > where you stored a system-dependent module that provided the
> > > > OS-specific functionality.  But there's some performance compromise
> > > > there (probably too small to matter compared to a system-call,
> > > > though), and I'm not sure it comes out cleaner.
> >
> > > > y
> >
> > > > --
> > > > Yaron Minsky
> >
> > --
> > Yaron Minsky
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ocaml.org/pipermail/core/attachments/20111101/d1f7f667/attachment-0001.html>