Making Async play better with others

[Yaron Minsky]

Yury is hoping to get a proper bridging system for ferrying patches
back and forth to github done very soon, say, in another week.  If we
can't get it done, we'll try something simpler as an intermediate
step.

In any case, we'd be very happy to accept portability patches!
Stephen, what do you think about Markus' proposal for how to organize
it?  It's worth noting that this patch might conflict with a patch
that Stephen has done internally that reorganizes much of Async's
internals to separate out a small core that is independent of all
OS-specific code.

So, in short, give us another week!

y

On 21/11/11 08:53, Markus wrote:
> 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

-- 
Yaron Minsky