It's been really nice to see these updates from the multicore team. I'm looking forward to the systhread support using the Domain/Atomic modules. Being able to build recent versions of dune is something i'm looking forward to. That'll make it really easy to try (and hopefully contribute/port examples and benchmarks) to the multicore project.

When is it expected to be released?

(Speaking personally and not for OCaml Labs who are driving most of the multicore work at the moment)

You can use multicore right now: https://github.com/ocaml-multicore/ocaml-multicore though it's currently at an older version of OCaml, 4.06.1.

There's work currently going on to rebase on to OCaml trunk, show-stopping bugs aside there should be a more up to date version of multicore in the next couple of months - then the focus will be on upstreaming.

Hard to give a reasonable timeframe for release because that's going to depend a lot on how things get upstream.

As asked before:

In what form will Multicore OCaml support the, you know, multicore stuff? Will it be native OS threads? CSP? Actors? Something else?

(I work on Multicore OCaml)

Multicore OCaml separates the notion of concurrency (overlapped execution) and parallelism (simultaneous execution). You can have one without the other but also have both. The main principle that we're going for is that the compiler should expose just enough support for concurrency and parallelism such that interesting features can live outside the compiler as libraries. This permits the library evolution not to be tied with the language evolution but also permits diversity of libraries beyond what the language developers can aim to achieve. That said, we will build and maintain a few core libraries for concurrency and parallelism.

For concurrency, Multicore OCaml exposes effect handlers [1,2,3] which allows you to build generators, async/await, coroutines, etc as library functions (as opposed to primitives natively supported by the compiler). For example, have a look at aeio [4] which permits the construction of scalable asynchronous I/O in direct-style (no callbacks). aeio is also discussed in [1]. We also plan to extend Lwt to support parallelism.

For parallelism, the compiler exposes Domains, which are a wrapper over OS-threads [5]. Domains expose a low-level API that is not suitable for end user consumption. On top of domains, we support channels with bounded buffers [6] (similar to channels in Go, Mvars in GHC Haskell) as well as software transactional memory (STM) that supports shared memory and message passing concurrency and which can take advantage of hardware transactional memory [7].

[1] Concurrent System Programming with Effect Handlers: http://kcsrk.info/papers/system_effects_feb_18.pdf

[2] CUFP effects tutorial: https://github.com/ocamllabs/ocaml-effects-tutorial

[3] Effects Examples: https://github.com/kayceesrk/effects-examples

[4] Aeio: Asynchronous Effect-based IO https://github.com/kayceesrk/ocaml-aeio

[5] Domains: https://github.com/ocaml-multicore/ocaml-multicore/blob/para...

[6] domainslib: https://github.com/ocaml-multicore/domainslib

[7] Reagents: https://github.com/ocaml-multicore/reagents

Thank you for the extremely informative answer! It was very helpful.

Another question, if you allow me:

Will you provide preemptive scheduling primitives? Or will they be possible through the more low-level interface you described?

IMO preemptive scheduling is something that's very necessary nowadays, especially with the explosion of CPU core count.

I am not sure I understand the suggestion that preemptive scheduling is important with the explosion of CPU core count. You may need preemptive scheduling even on a single core if your application expects some fairness of scheduling guarantees. Am I missing something?

We can do preemptive scheduling of user-level threads by registering a timer interrupt with the OS and preempting the currently running user-level thread in favor of another one. This is up to the individual libraries to implement. These issues are discussed in [1] Sec 4.3.

No, you're not missing anything -- I was just saying that it would be a shame if people still can't code preemptively scheduled parallel apps when the average home gaming machine is going to have 16 cores soon and that many devs (me included) are looking to buy a 32/64-core workstation. Nothing else. :)

Really exciting that preemption is possible. Thanks for your insights!