Allow newly spawned domains to have a copy of the parent domain's local state

[kayceesrk]

Currently, when domains are spawned, their domain-local states start off as empty. It is conceivable that one may want a newly-spawned domain to have a copy of the parent state rather than starting a fresh. This feature was suggested by @lpw25 here.

This feature can be implemented fairly easily by copying the parent domain's domain local state array.

[gasche]

Currently (in #582) domain-local state is initialized with a init : unit -> 'state function passed at key-creation-time. The proposal in this issue is to have something like { root : 'state; from_parent : 'state -> 'state } instead. To support the use-case of splittable generators, we need something yet more elaborate: { root : 'state; split_parent : 'state -> 'state * 'state }, with one side setting the parent state and the other becoming the new child state.

It is possible to emulate split_parent a version of from_parent that mutates its input, if the computation is guaranteed to run in the parent's domain, with the result copied, instead of copying the parent state and running the update in the child domain.

One downside of the split_parent version is that the parent domain must block until the split_parent value is available: this sequentializes the creation of many domains instead of letting children domains do their initialization work. If this was an issue it would be possible to split the API even further, something like { root : 'state; on_parent : 'state -> 'state * 'spawn_data; on_child : 'spawn_data -> 'state }, with the parent-state-independent compute being done by the child explicitly.

[xavierleroy]

To support the use-case of splittable generators, we need something yet more elaborate: { root : 'state; split_parent : 'state -> 'state * 'state }, with one side setting the parent state and the other becoming the new child state.

The latest proposal for a splittable Random module (ocaml/ocaml#10742) has split that modifies the parent generator in place and returns the new generator as a result. So, it would be enough to have an initialization function unit -> ty and a flag telling whether it should be run in the parent domain at the time of Domain.spawn, or in the child domain the first time the DLS key is looked up.

[gasche]

or in the child domain the first time the DLS key is looked up.

If I understand correctly, we would need this "lazy split" to modify the parent generator from the child domain, which would require synchronization, right? (This would also not be deterministic.)

[xavierleroy]

If I understand correctly, we would need this "lazy split" to modify the parent generator from the child domain, which would require synchronization, right? (This would also not be deterministic.)

What I meant: some DLS slots, such as the slot for the PRNG state, are declared "initialized by parent domain", and the computation of the initial value is run in the parent domain; while other slots are declared "initialized by child domain", and the computation of the initial value is run in the child domain, probably at first lookup, like in the current implementation. So, there is no lazy split of a PRNG state. But there can be lazy initialization of other DLS slots, either because the initialization must be run on the child domain (e.g. it refers to the child domain identifier), or just because it's more efficient.

[kayceesrk]

Fixed by ocaml/ocaml#10887.