OCaml Weekly News

Breaking the C API is a consequence of deciding that all single-threaded shared mutable state must assume they are also shared between threads. So a new read barrier is used to promote values when read from another thread. But for data types that were correct up to now, users must also be careful to avoid races from now on… for instance by avoiding sharing values of such types between domains.

One lesson of Rust is that there are different kinds of mutable state, for different usages, with different means to achieve thread-safety.

The closest there is to current OCaml's mutable is the notion of single-threaded multiple-writers mutable state (Cell). It is made thread-safe in Rust by statically preventing values containing Cell from crossing thread boundaries (by virtue of not having the Send trait). The same restriction is used to make some data structures more efficient by avoiding the cost of synchronisation (cf. the reference-counting pointer Rc vs. the atomic reference-counting pointer Arc).

This is not enough by itself, and Rust offers other kinds of state for communicating and sharing values between threads.

UnsafeCell like Ocaml multicore's mutable (though yours is safe thanks to the work on the memory model): it has almost no restriction and can be sent across domains, but the user is likewise told to “avoid data races”. It is rarely used alone, but together with type abstraction it can be used to program safe concurrent data structures.

Lastly, the default notion of state in Rust is linear state, which can be sent freely across threads. Thread-safety is ensured by restricting aliasing using the ownership and borrowing discipline.

If I had to imagine a backwards-compatible OCaml with static control of interference à la Rust based on ConcMinor, it would distinguish the three kinds of state (concretely with other keywords in addition to mutable). mutable would keep its current meaning of single-domain, multiple-writers state and not require a read barrier, and in particular preserve the API. (I count systhreads as single-threaded for this purpose, since here it means "sharing the same minor heap".)

Programs could progressively transition to other kinds of state when parallelising the program. Concretely, a data structure like Stack.t, instead of becoming racy, would keep its current meaning, but users could replace it with a linear stack or a concurrent stack, two data structures distinct from the first one, when parallelizing their programs.

So how could this fit with the current plans? It is not entirely clear to me. If people start to rely on parallelism in an unstructured way (e.g. no clear distinction between different kinds of data types arising from different ways of ensuring thread-safety) then one will also lose the ability to retrofit ConcMinor in a backwards-compatible manner (by losing the information that the current mutable API is single-threaded). The API breakage of ConcMinor which might only be virtual right now (if I trust this preliminary, not fully-explored idea) will become real. (Further difficulties arise with the emulation of the Thread library with domains, but this could be changed later.)

But if users are provided in advance with a general direction for a model of control of interference this might happen differently. And eventually having such a model is desirable in any case, as it helps parallelizing programs (for instance the Firefox people reported that they had attempted and failed twice to parallelise the CSS engine in C++ before succeeding with Rust). Furthermore, in an imaginary retrofitting of ConcMinor, one could imagine enforcing something like the Send trait at the level of the read barrier until there is a better way (there would be two kinds of barriers, one of which would raise an exception if a state happened to be incorrectly shared across domains, and not be required in the FFI).

I find ConcMinor interesting from a systems programming perspective compared to the stop-the-world collector because it could (I hope) offer possibilities such as having a low-latency domain communicating with a higher-latency domain. Moreover the performance cost of the read barrier might be lower in this scheme if it could be removed for all but the concurrent data structures.

Both libraries involve promises/futures. Async calls its promises Deferred.t, whereas in Lwt they're called Lwt.t.

In Async you start your program by saying never_returns (Scheduler.go ()) or Command.async_spec after you set up your initial Deferred.t.

In Lwt you say Lwt_main.run on a top-level Lwt.t argument. Note you can re-run Lwt_main.run in a single program as many times as you want, but perhaps you shouldn't run multiple Lwt_main.run in parallel.

There's an easy correspondence between basic operators.

The most important difference between Async and Lwt is that fulfilled promises are acted on immediately, whereas Async kinda punts them to the end of a work queue and runs their thunks later.

A return loop like this starves the rest of Lwt:

open Lwt.Infix

let main () =
  let rec loop () =
    Lwt.return ()
    >>= fun () ->
    loop ()
  in
  Lwt.async (loop ());
  Lwt_io.printlf "this line never prints!"
;;

let () = Lwt_main.run main ;;

whereas the corresponding Async loop does not starve:

open! Async

let main () =
  let rec loop () =
    Deferred.return ()
    >>= fun () ->
    loop ()
  in
  don't_wait_for (loop ());
  printf "this line does print!\n";
  return ()
;;

let () =
  let cmd = Command.async_spec ~summary:"" Command.Spec.empty main in
  Command.run cmd
;;

Fortunately there's a workaround. You can get something closer to the Async-style behavior in Lwt by using Lwt.yield () instead of Lwt.return ().

From time to time you may need to run something in a system thread. In Async you say In_thread.run, whereas in Lwt you say Lwt_preemptive.detach. For simple things they're pretty much interchangeable, but one stumbling point for me was that in Async you can create a named thread and always use that for the In_thread.run, with multiple simultaneous dispatches to that thread becoming sequenced.

This is really useful for interacting with libraries that aren't so thread friendly.

Lwt's detach doesn't provide an easy way to do this out of the box, but I think you can still deal with thread unfriendly libraries by using the Lwt_preemptive.run_in_main call.

Basically, never exit the detach thread you started to interact with your library, and instead have it block on promise that gets filled through run_in_main. In this way you can sequence your detached Lwt thread similarly to Async.

Happy to explain further if this is unclear.

Async.Unix has a somewhat built-up conception of the UNIX API, whereas Lwt_main is more a direct mapping of ocaml's Unix module to promises.

Async Clock.every and Clock.after don't have exact analogs, but you can make new versions pretty simply.

Example of a shallow imitation of Async Clock.every

let every span f =
  Lwt.async (fun () ->
    let span = Time.Span.to_sec span in
    let rec loop () =
      f ();
      Lwt_unix.sleep span
      >>= fun () ->
      loop ()
    in
    loop ())
;;

Open questions

I haven't sorted out a good Lwt substitute that's as comfortable as Async Pipe yet. Though some combination of Lwt_stream, Lwt_sequence and lwt-pipe might fit the bill. If you just happen to know already feel free to cluephone.

This is basically everything? I'm almost suspicious that I'm not having more problems, but will happily accept grace when it arises.

AV (Audio/Video) editors are responsible for previewing the presentations and providing help and feedback to the authors. Ideally we target for one editor per talk.

Session hosts will assist session chairs in streaming the pre-recorded videos as well as helping and moderating the Q&A sessions and the panel session. They will also be responsible for security and be ready to react to potential threats and wrongdoers. Since we will broadcast sessions in several time zones we need several hosts for each session.

We would like to have at least English transcriptions for each talk and translations to other languages are very welcome. Transcriptions enable accessibility as well as potentially increase the audience and publicity as they could be indexed by the search engines.

The content manager will be responsible for maintaining the web presence of the conference on https://ocaml.org/. We plan to have all videos available, as well as maintain a page for each submitted work.

We are striving to make the conference accessible to everyone and we are looking for volunteers who have experience in online accessibility.