Making Async play better with others

[Markus]

Concerning Async portability to non-Linux platforms, I think there are
a few trivial API issues, not just there but also in Core, which can
be fixed quickly.  E.g. Core.Bigstring_marshal is excluded on non-
Linux platforms even though there is only a single (and not super-
important) function in there that uses Linux-specific I/O.  Since the
Async writer accesses this module, Async cannot compile on non-Linux
platforms.

I suggest moving all functions that require Linux-specific
functionality to "Linux"-submodules within their current modules, both
in Core and Async.  These sub-modules should be compiled
conditionally.  This is an easy and clean way to propagate Linux-
functionality through all libraries.

The Core/Async issues could probably be solved within 2-3 hours
including making Godi packages, but would be considerably easier to
deal with if there were a public VC repository for both.  Async is
still lacking one.  Since the move to github is apparently taking it's
time, I'd be willing to add Async to OCaml Forge for the while being
and make the required patches to both Core and Async.

Please let me know if Jane Street is willing to merge the patched
versions of Core and Async on OCaml Forge.  Otherwise I'll hold off
until Jane Street creates a public repository where contributions can
be made to avoid unnecessary forking or losing work.

Cheers,
Markus

On Oct 31, 9:25 am, Yaron Minsky <ymin... at janestreet.com> 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