You asked about correctness rules in a FFI context, so I’m thinking about writing C code that manipulates OCaml values (and interacts with OCaml code manipulating those values). For C codes that manipulates C values, use the C rules. For OCaml code, you can use OCaml locks/mutex/whatever to provide mutual exclusion, and use Atomic.t for any shared mutable value whose access is not otherwise synchronized.
I think that the instructions are perfectly fine with the multicore runtime: if something is not thread-safe, then in particular it is not domain-safe, so users are not going to do anything unsafe if you tell them it is not thread-safe.
My understanding of the Sqlite documentation is that:
- if users ask for
mutex:Full(serialized mode), they can use their connections from multiple threads (and multiple domains) safely - if users ask for
mutex:No(multi-threaded mode), they have to avoid sharing connections between threads (and between domains) or protect them with a lock.
(Your instructions just say “connections are not thread-safe”. Are they not thread-safe even if you pass mutex:Full? It looks your instructions are more restrictive than what the SQLite documentation suggest, so I guess I’m a bit confused / missing something here.)
More details: before OCaml applications using threads were “not quite multi-threaded” because of the runtime lock, a single mutator (OCaml code) was running at a time. The Multicore runtime does not have that restriction, and that is basically it. (OCaml threads running on the same domain share a runtime lock, but each domain has an independent runtime lock.) In particular, the threading/concurrency recommendations that do not assume a single runtime lock, that do not depend on the existence of a single runtime lock for correctness, they remain perfectly valid with Multicore OCaml. I believe that your documentation is an instance of this.