Multicore OCaml team has been working on ensuring that the stdlib remains backwards compatible and fast for sequential programs, and provides reasonable behaviour when used in parallel by multiple domains. We've written down the guarantees we expect to provide when stdlib is used in parallel. In particular, we propose not to provide thread-safety by default as this would slow down sequential programs. Hence, mutable data structures such as queues will not be thread-safe but remain type-safe. We would also like observationally pure interfaces to remain so even when used in parallel. We have made the internal mutable states in random, filename and hashtbl to be domain-local (PR#582).

Format

Similarly, format also has some global state, which causes issues in functions such as Format.printf when used in parallel, though they appear to be observationally pure. We would like to fix Format.printf such that they avoid unexpected behaviours -- such as raising Stdlib.Queue.Empty exception.

However, unlike the other modules, the global state used in format is exposed by the interface. In particular, the formatter type includes mutable state, and the interface exposes this mutable state in
std_fomatter, err_formatter, str_formatter, but also std_buf. Since accessing domain-local state in Multicore OCaml needs to run code on the requesting domain, the current interface cannot be supported as is.

Proposal

The multicore team would prefer not to introduce a breaking change. Hence, our plan is to

1. Introduce domain-local format buffers for stdout, stderr and string formatters. This will fix Multicore OCaml Issue #563.
2. Update the documentation associated with values std_formatter, err_formatter, str_formatter and std_buf to indicate that they are the formatters and buffer used by the initial domain.
3. Provide additional functions to access the domain-local stdout, stderr and string formatters and the string buffer.

We request your comments on this proposal. We plan to adopt a similar strategy for other global states that may be exposed by stdlib.