Comment author: gerd

Another use cases: The Random module could become thread-safe

There are also (rare) occasions where you are changing the global properties of a process temporarily, and you don't want that other threads see this (e.g. chdir, umask)

Comment author: @xavierleroy

Preventing preemption between threads is easy -- the bytecode threads implementation (otherlibs/threads) does it to implement mutex. Preventing other forms of context switches between threads (e.g. a thread blocks on a Unix.read) feels weird to me. I'm a bit unsure about signals, and very unsure about GC-related actions. Queuing finalizers to be run later sounds painful to implement.

Comment author: gerd

Interesting reaction. I was prepared to hear more fundamental objections, e.g. that this change makes all other approaches to integrating multi-threading more difficult or impossible (especially those targeting multicore). Or that programmers could use the feature in the wrong way, and especially keep the lock for too long.

My intention is that it becomes easier to program signal handlers and GC hooks in Ocaml. I've more than once moved such code, especially finalizers to the C level, because I get there implicitly the described effect. If you stick to Ocaml, you often cannot do more than setting some flag, and do the real finalization later. As an example look at the memory pool implementation in Ocamlnet: https://godirepo.camlcity.org/svn/lib-ocamlnet2/trunk/code/src/netsys/netsys_mem.ml (at the end of the file, look for type memory_pool). A memory pool is a manager for page-aligned bigarrays of char. The finalizer cannot here do much, because in a multi-thread program it is impossible to lock the data structure from the finalizer (deadlock danger). In this case, it was possible to just delay finalization, but I can imagine other cases where one does not want this, because the resources to free are more valuable than just memory.

If Sys.critical would only prevent preemption and maybe signal handlers, it would already make a lot of such things easier (especially in a finalizer, because the execution of finalizers is serialized anyway). The idea to also include GC hooks in general is just for completeness of the concept.

Comment author: @lefessan

Your assumption was correct, we discussed the issue, and "fundamental objections" were raised, by those ones who would like to have a multicore runtime soon...