Hoist value access outside section without lock

[contificate]

The runtime lock is not being held when String_val(...) is used on OCaml values. Instead, we duplicate the strings whilst holding the lock, then use (and free) the values without the lock.

---

Thanks to @last-genius for spotting this. It's a bad pattern used in other places with less consequence (e.g. Int_val is unboxed and cannot be relocated), but they should all be changed - I just wanted to quickly address this in particular, since it's my mistake.

[lindig]

Is the release of the runtime lock in this case an optimisation and this would work without releasing it? The OCaml value is copied to local variables, which can't move, and later the memory is freed.

[contificate]

Is the release of the runtime lock in this case an optimisation and this would work without releasing it? The OCaml value is copied to local variables, which can move, and later the memory is freed.

Yeah, the lock could remain held for the duration of the call. I believe, on some implementations, you can configure the setting parameter such that it expends a lot of iterations within crypt_r, so it's released here to allow other threads to be scheduled while we do that.

The problem in the previous code is that the lock is released but then we refer to an OCaml (block) value which, as you say, could be relocated by another thread triggering GC movement. There are other cases where this is done which we should guard against, as pointed out by Andriy, but those are less important as they are working with local values (like integers passed by value from OCaml to C, so no chance of dereferencing a moved object). Still, we should abide by the OCaml manual and ensure we aren't doing that everywhere. I wanted to quickly address this snippet in particular because I wrote the erroneous stub.