You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Original bug ID: 4787 Reporter:@mmottl Status: closed (set by @mshinwell on 2016-12-07T13:27:32Z) Resolution: won't fix Priority: normal Severity: feature Version: 3.11.0 Category: ~DO NOT USE (was: OCaml general) Monitored by:@ygrek@glondu@Chris00@mmottl
Bug description
I have run into a problem that seems extremely hard to fix without support in the runtime, but adding this feature to the OCaml runtime is probably quite easy.
A library I have created bindings for supports callbacks from C, which I would like to pass on to OCaml. The thread executing this callback comes from OCaml, but unfortunately I cannot tell beforehand whether it still holds the OCaml-lock at the time of the callback, because there is a large number of entry points, only some release it, and the thread does not hold information as to from which entry point it was coming from.
caml_leave_blocking_section cannot be called when the runtime lock is still being held (-> deadlock) and not calling it if it isn't (-> race) is also not an option so I am stuck. There is currently no exported functionality in the runtime to discover whether the executing thread holds the runtime lock.
Would it be possible to either support recursive acquisitions of the runtime lock or provide for a way to determine whether the running thread holds it? Thanks!
The text was updated successfully, but these errors were encountered:
It seems the easiest and most efficient way to support the requested feature could be the following, and it would even add a safety measure for free:
Export an alternative to the "caml_leave_blocking_section" function, which does the same thing, but returns whether the runtime was already being held by this thread. This function would behave mostly like the ordinary one, but does following:
lock caml_runtime_mutex
use pthread_getspecific right away to get pointer to thread descriptor.
compare this pointer with curr_thread. If different, do the usual thing and return that the runtime needed to be acquired. Otherwise, if the pointers are the same, unlock the mutex, and return instantly with the result that the runtime was already being held by this thread.
The ordinary function could be implemented in terms of the new one. Furthermore, this would then also allow cheap checking of an important invariant: if the ordinary function for leaving blocking sections gets the result that the runtime was already being held by this thread, it could print a deadlock error to stderr before calling "abort" (to get a core dump), which is certainly more useful than just silently hanging forever.
The alternative function would certainly allow me to solve my problem.
I think this is unlikely to be implemented, especially with ongoing work on Multicore OCaml. The situation described seems quite niche and I would have thought could be addressed by other means (e.g. a thread-safe queue filled by the C callbacks and read from the OCaml side).
Original bug ID: 4787
Reporter: @mmottl
Status: closed (set by @mshinwell on 2016-12-07T13:27:32Z)
Resolution: won't fix
Priority: normal
Severity: feature
Version: 3.11.0
Category: ~DO NOT USE (was: OCaml general)
Monitored by: @ygrek @glondu @Chris00 @mmottl
Bug description
I have run into a problem that seems extremely hard to fix without support in the runtime, but adding this feature to the OCaml runtime is probably quite easy.
A library I have created bindings for supports callbacks from C, which I would like to pass on to OCaml. The thread executing this callback comes from OCaml, but unfortunately I cannot tell beforehand whether it still holds the OCaml-lock at the time of the callback, because there is a large number of entry points, only some release it, and the thread does not hold information as to from which entry point it was coming from.
caml_leave_blocking_section cannot be called when the runtime lock is still being held (-> deadlock) and not calling it if it isn't (-> race) is also not an option so I am stuck. There is currently no exported functionality in the runtime to discover whether the executing thread holds the runtime lock.
Would it be possible to either support recursive acquisitions of the runtime lock or provide for a way to determine whether the running thread holds it? Thanks!
The text was updated successfully, but these errors were encountered: