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

[Yaron Minsky <yminsky@janestreet.com>]

Right now, only select and epoll are supported, but adding support for
something else isn't hard.  The Async_unix library has an interface
called File_descr_watcher_intf.S, which both select and epoll go
through.  Adding support for another shouldn't be difficult if someone
with the right OS expertise wants to do it.

Is there a particular kernel API you want support for?

y

On Mon, Mar 7, 2016 at 1:16 PM, Malcolm Matalka <mmatalka@gmail.com> wrote:
> Yaron Minsky <yminsky@janestreet.com> writes:
>
>> This is definitely a fraught topic, and it's unfortunate that there's
>> no clear solution.
>>
>> To add a bit more information:
>>
>> - Async is more portable than it once was.  There's now Core_kernel,
>>   Async_kernel and Async_rpc_kernel, which allows us to do things like
>>   run Async applications in the browser.  I would think Windows
>>   support would be pretty doable by someone who understands that world
>>   well.
>>
>>   That said, the chain of dependencies brought in by Async is still
>>   quite big.  This is something that could perhaps be improved, either
>>   with better dead code analysis in OCaml, or some tweaks to
>>   Async_kernel and Core_kernel themselves.
>
> When I last looked at the scheduler it was limited to [select] or
> [epoll], is this still the case?  How difficult would it be to expand on
> those?
>
>>
>> - There are things we could contemplate to make it easier to bridge
>>   the divide.  Jeremie Dimino did a proof of concept rewrite of lwt to
>>   use async as its implementation, where an Lwt.t and a Deferred.t are
>>   equal at the type level.
>>
>>     https://github.com/janestreet/lwt-async
>>
>>   Another possibility, and one that might be easier to write, would be
>>   to allow Lwt code to run using the Async scheduler as another
>>   possible back-end.  This would allow one to have programs that used
>>   both Async and Lwt together in one program, without running on
>>   different threads.
>>
>> It's worth mentioning if that there is interest in making Async more
>> suitable for a wider variety of goals, we're happy to work with
>> outside contributors on it.  For example, if someone wanted to work on
>> Windows support for Async, we'd be happy to help out on integrating
>> that work.
>>
>> Probably the biggest issue is executable size.  That will get better
>> when we release an unpacked version of our external libraries.  But
>> even then, the module-level granularity captures more things than
>> would be ideal.
>>
>> y
>>
>> On Mon, Mar 7, 2016 at 10:16 AM, Jesper Louis Andersen
>> <jesper.louis.andersen@gmail.com> wrote:
>>>
>>> On Mon, Mar 7, 2016 at 2:38 AM, Yotam Barnoy <yotambarnoy@gmail.com> wrote:
>>>>
>>>> Also, what happens to general utility functions that aren't rewritten for
>>>> Async/Lwt -- as far as I can tell, being in non-monadic code, they will
>>>> always starve other threads, since they cannot yield to another Async/Lwt
>>>> thread. Is this perception correct?
>>>
>>>
>>> Yes.
>>>
>>> On one hand, your observation is negative in the sense that now your code
>>> has "color" in the sense that it is written for one library only. And you
>>> have to transform code to having the right color before it can be used. This
>>> is not the case if the concurrency model is at a lower level[0].
>>>
>>> On the other hand, your observation is positive: cooperative scheduling
>>> makes the points in which the code can switch explicit. This gives the
>>> programmer far more control over when you are done with a task and start to
>>> process the next task. You can also avoid the preemption check in the code
>>> all the time. If your code manipulates lots of shared data, it also
>>> simplifies things since you don't usually have to protect data with a mutex
>>> in a single-threaded context as much[1]. Cooperative models, if carefully
>>> managed, can exploit structure in the problem domain, whereas a preemptive
>>> model needs to fit all.
>>>
>>> My personal opinion is that the preemptive model eventually wins over the
>>> cooperative model, much like it has in most (all popular) operating systems.
>>> It is simply more productive to take an up-front performance hit as a
>>> sacrifice for a system which is more robust against stray code misbehaving.
>>> If a cooperative system fails, it is fails catastrophically. If a preemptive
>>> system fails, it degrades in performance.
>>>
>>> But given I have more than 10 years of Erlang programming behind me by now,
>>> I'm obviously biased toward certain computational models :)
>>>
>>> [0] Erlang would be one such example, where the system is preemptively
>>> scheduling for you and you can use any code in any place without having to
>>> worry about blocking for latency. Go is quasi-preemptive because it checks
>>> on function calls, but in contrast to Erlang a loop is not forced to factor
>>> through a recursion, so it can in principle run indefinitely. Haskell (GHC)
>>> is quasi-preemptive as well, checking on memory allocation boundaries. So
>>> the thing to look out for in GHC is latency from processing large arrays
>>> with no allocation, say.
>>>
>>> [1] Erlang has two VM runtimes for this reason. One is single-threaded and
>>> can avoid lots of locks which is far faster for certain workloads, or on
>>> embedded devices with a single core only.
>>>
>>> --
>>> J.