[kcsrk]

(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

[pdimitar]

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.

[kcsrk]

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.

[pdimitar]

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!