Making Async play better with others

[Dmitry Astapov]

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