eio

Instead of Stdlib.Queue you can use Eio.Stream, which is thread-safe (and will take care of waking sleeping threads when data becomes available). The README shows an example of a pool of workers pulling jobs from an Eio.Stream: https://github.com/ocaml-multicore/eio#example-a-worker-pool We're still exploring what APIs to provide for this kind of thing, and in particular how to unify domainslib and eio.

To clarify that, there are two systems here: - domainslib schedules all tasks across all cores (like Go). - eio keeps tasks on the same core (and you can use a shared job queue to distribute work between cores if you want). Eio can certainly do async IO on multiple cores. Moving tasks freely between cores has some major downsides - for example every time a Go program wants to access a shared value, it needs to take a mutex (and be careful to avoid deadlocks). Such races can be very hard to debug. I suspect that the extra reliability is often worth the cost of sometimes having unbalanced workloads between cores. We're still investigating how big this effect is. When I worked at Docker, we spent a lot of time dealing with races in the Go code, even though almost nothing in Docker is CPU intensive! For a group of tasks on a single core, you

OCaml is currently going through something similar, with some solutions in sight. The "motivation" part of the eio (https://github.com/ocaml-multicore/eio) documentation is a great introduction: "The Unix library provided with OCaml uses blocking IO operations, and is not well suited to concurrent programs such as network services or interactive applications. For many years, the solution to this has been libraries such as Lwt and Async, which provide a monadic interface. These libraries allow writing code as if there were multiple threads of execution, each with their own stack, but the stacks are simulated using the heap. The multicore version of OCaml adds support for "effects", removing the need for monadic code here. Using effects brings several advantages: 1. It's faster, because no heap allocations are needed to simulate a stack. 2.

Yes, exactly. The reason why monadic concurrency libraries such as Lwt and Async is that the OCaml language does not support concurrency natively. If it did, we would have built something similar to the `ocaml-aeio` library. Btw there is a modern instantiation of `ocaml-aeio` called `eieio` [1] which supports Linux's io-uring. Eventually, this will be extended to support all the modern I/O stacks on different platforms, and also support performing I/O on multiple cores. [1] https://github.com/ocaml-multicore/eioio

I'm not aware of large standalone projects that depend solely on it. Multicore is backwards compatible with stock OCaml though and 4.12 ships with some stub Atomics (https://github.com/ocaml/ocaml/blob/4.12/stdlib/atomic.mli) which makes writing programs that can work on both easier. We also maintain some projects on top of Multicore that are pretty interesting: * Domainslib - channels and task queue that makes using parallelism via Domains much easier: https://github.com/ocaml-multicore/domainslib * eioio - very much a work in progress but enables high performance direct-style IO with fibers and effects. Backs on to io_uring on Linux and is designed to also work with IOCP on Windows: https://github.com/ocaml-multicore/eioio