Split Lin interpretations

[jmid]

The MacOS segfault that KC just fixed in ocaml/ocaml#11250 reveals that the threads module performs a number of side-effects when loaded. By having all three of our Lin interpretations (Domain,Thread,Fiber) in the same module requiring threads (even though it isn't used) this means

• we confine our test runs to those where thread is always loaded and its callbacks are registered - see https://github.com/ocaml/ocaml/blob/37dec39a627b3b8abcf84c2463c64d2336b2bee6/otherlibs/systhreads/thread.ml#L87-L98
• Domain tests will run slower than necessary because of the overhead

The latter is naturally less serious than the first.

We should consider splitting the three interpretations up into separate files with separate dependencies such that only the Lin Thread interpretation requires threads.

[jmid]

Ideally a design would

• allow us to keep a Lin (or STM) specification in one, common file
• run both a Domain or Thread interpretation from the same specification (for either Lin or STM)
• allow only the Thread interpretation to require threads
• (be as simple as possible)

This way

• a specification is reusable
• a pure Domain interpretation executable does not perform the side-effecting load of threads
• one is still able to test this corner-case configuration by loading threads nevertheless
• one can write the "alternative printer interpretation" (Domain-safety: Atomic: OK ... Hashtbl: No ...) we initially talked about

[n-osborne]

I've begun to experiment with building the Domain and the Thread tests with two different functors in two different files (so we have a STM_Domain.Make(Spec) and a STM_Thread.Make(Spec)), most of the work being done by an intermediary common functor.

There is the question of the sequential agree_test. Do we want also a STM_Sequential.Make(Spec)?
I think it would be cleaner, but maybe there are other options I didn't consider?

[jmid]

Good point! 👍
I think a separate sequential functor would be good - akin to what qcstm offers.

[jmid]

Fixed in #164