I've been hacking on the OCaml multicore GC recently and am happy to answer questions anyone has.
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.
In what form will Multicore OCaml support the, you know, multicore stuff? Will it be native OS threads? CSP? Actors? Something else?
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
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.
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.
Really exciting that preemption is possible. Thanks for your insights!