One problem we have in the discussion of the domain-local-storage vs. thread-local-storage discussion is that we cannot write code that relies on the Thread module in the runtime or stdlib, because that module depends on Unix and therefore needs to stay in otherlibs.

If we look at the Thread interface (otherlibs/systhreads/thread.mli), we see that it has two halves, one that is about thread creation and thread operation, whose implementation only depends on pthreads, not Unix, and another about exposing Unix stuff for threads (wait, select, signals, stuff), which does depend on Unix. This suggests that we should be able to split the Thread implementation in two, a camlinternalThread module in the stdlib which does not depend on Unix, and the rest in otherlibs/systhreads.

The present PR implements a first step in this direction: it moves the runtime code for threads from otherlibs/systhreads to runtime/, to become part of the main OCaml runtime. This is just fine as the OCaml 5 runtime already depends on pthreads anyway.

This is "very easy", which means that it took me 90 minutes of battling with the build system.

How

I had to deal with the following issues.

1. The systhreads code plays weird tricks, there is a st_stubs.c file that includes either st_posix.h or st_unix.h, they both include st_pthreads.h (while defining some functions that st_pthreads rely on), and none of those .h files are actually public headers (there is one, caml/threads.h), my guess is that the authors just felt that including .c files would be too naughty. And then the Makefile code to compute dependencies over this is above my paygrade.

   I mirrored this exact same structure inside runtime/. I had to tell Makefile.common that there are header files in runtime/*.h now, not just in runtime/caml/*.h. (I considered turning st_posix.h and st_win32.h into .c files instead, but I suspect that this would have broken the dependency computation in horrible ways.)

2. The names st_foo.[ch] made sense inside a systhreads/ directory (hint: 'st' is for 'systhreads'), but they become obscure inside runtime/, so I had to perform a ritual sacrifice to the Gods of Bikeshedding and their oracle suggested the following rename: otherlibs/systhreads/st_stubs.c is now runtime/threads.c, the files otherlibs/systhreads/st_{posix,win32,pthreads}.h are now runtime/threads_{posix,win32,pthreads}.h, and otherlibs/systhreads/caml/threads.h is just runtime/caml/threads.h. The functions in those files, of course, keep their st_ prefix when they have one.

3. The code in otherlibs/systhreads/thread.ml has external declarations for some caml_thread_* functions, some of which were registered as CAMLprim and some were not. You would think that it's just a matter of adding CAMLprim on those functions, but they are defined in runtime/threads_{posix,win32}.h and the primitive-listing machinery only inspects C files. The solution is to add forward CAMLprim declarations for these primitives in threads.c.

4. I naively thought that otherlibs/systhreads would become massively simpler after the change, due to now being a pure-OCaml library. But otherlibs/systhreads builds C archives called libthreads{,nat}.a, and who knows what third-party tools and build scripts will break if this file suddenly wasn't installed anymore, right? Mathematicians would naturally think of building an archive from the empty set of object files, but this is broken on most toolchains, so instead I created a dummy C file (st_dummy.c) to build instead of st_stubs.c, which now populates the libthreads* archives.

   I suppose that some of the logic (maybe all) in otherlibs/systhreads/Makefile could be simplified now that there is morally no C code anymore, but this is not my expertise and I decided to leave it outside the scope of the present PR.

The future

Two things can be considered if this PR is merged:

• We can move a subset of the Thread module to camlinternalThread, which could be useful, for example, to expose thread-local storage in the standard library. I am planning to work on this next.
• We can simplify the C runtime code for threads, now that it sits within the runtime proper, to stop acting like a third-party citizen that needs to register hooks to do anything, adding some fragility. This could eventually give us a noticeably simpler result, fix some corner cases of the code that are probably subtly broken by now, etc. But these will also be subtle changes that will need to be written and reviewed carefully. I am not planning to work on this for now.