Re: [Caml-list] Question about Lwt/Async

[Malcolm Matalka <mmatalka@gmail.com>]

Jeremie Dimino <jdimino@janestreet.com> writes:

> On Tue, Mar 8, 2016 at 12:47 PM, Yaron Minsky <yminsky@janestreet.com>
> wrote:
>
>> Jeremie, other than having some different back-ends available (e.g., glib
>> main loop), how different are the approaches to backend management between
>> Async and Lwt?
>>
>
> ​The backend interfaces are slightly different​, but we just need a bit of
> glue in the middle. Essentially the difference is that with Lwt you provide
> one callback per fd and watch (read or write), while with Async you have a
> global callback.
>
> ​Right now what we need to change in Async to make this work is:
>
> - allow to provide a backend ​programmatically; right now you can only
> choose between the predefined epoll and select ones
> - make the scheduler ignore fds returned by the backend that are not
> handled by async

For what it's worth, which isn't much right now, I've been slowly
developing an interface point for event loops and user facing code.  The
rough idea is to present "asynchronous system calls" like an OS would,
so user facing code has an interface to program against and the
underlying event loop can change as someone wants, libev, libuv, direct
epoll or kqueue, etc.  So Async and Lwt libraries could be implemented
in terms of this interface and share the same event loop, to cooperate
nicely.  So far I haven't implemented anything using the interface
except for a barely functional test to demonstrate that it even works,
so it's quite raw.  And it's clearly deficient on a few things, but I
think the idea is sound and would alleviate some of the pain of deciding
to use Lwt or Async and if it works on JS or Windows or My Favorite OS
(just flip out the underlying scheduler implementation).

The work in progress around the interface can be found below, any
constructive feedback would be appreciated.

https://bitbucket.org/acslab/abb_scheduler_inf/src