|Anonymous | Login | Signup for a new account||2017-05-23 14:41 CEST|
|Main | My View | View Issues | Change Log | Roadmap|
|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0004787||OCaml||~DO NOT USE (was: OCaml general)||public||2009-05-07 02:54||2016-12-07 14:27|
|Target Version||Fixed in Version|
|Summary||0004787: Acquisition of runtime lock|
|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!
|Tags||No tags attached.|
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:
1) lock caml_runtime_mutex
2) use pthread_getspecific right away to get pointer to thread descriptor.
3) 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).|
|2009-05-07 02:54||mottl||New Issue|
|2009-05-07 19:02||mottl||Note Added: 0004952|
|2009-05-15 17:01||doligez||Status||new => acknowledged|
|2016-12-07 14:27||shinwell||Note Added: 0016707|
|2016-12-07 14:27||shinwell||Status||acknowledged => closed|
|2016-12-07 14:27||shinwell||Resolution||open => won't fix|
|2017-02-23 16:36||doligez||Category||OCaml general => -OCaml general|
|2017-03-03 17:55||doligez||Category||-OCaml general => -(deprecated) general|
|2017-03-03 18:01||doligez||Category||-(deprecated) general => ~deprecated (was: OCaml general)|
|2017-03-06 17:04||doligez||Category||~deprecated (was: OCaml general) => ~DO NOT USE (was: OCaml general)|
|Copyright © 2000 - 2011 MantisBT Group|