Open mmottl opened 8 years ago
Maybe such complicated semantics should better be reflected more declaratively in the user code. I guess one could add a primitive to the Gc
module in the standard library for that, e.g.:
external keep_until_now : _ -> unit = "%keep_until_now"
The only effect would be to force a potential optimizer to keep the value registered with the GC until at least Gc.keep_until_now
is called on the value.
This may not be an actual issue but could be a potential one so I'd like to make sure this is noted somewhere. Consider the following code:
If
t
has a finalizer, accessingt.foo
within the lock should guarantee thatt
is still around while the mutex is locked. This may be necessary if the finalizer, too, makes use of the lock. Butfoo
is immutable so an overly clever optimization might decide to not hold on tot
, extractingfoo
before the mutex is locked. I think such optimizations should be avoided (maybe they already are).Making
foo
a mutable record field would presumably prevent such an optimization in any case, but may not reflect the user's intention of keeping the field immutable.