|Anonymous | Login | Signup for a new account||2019-01-17 17:54 CET|
|Main | My View | View Issues | Change Log | Roadmap|
|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0007709||OCaml||threads||public||2018-01-14 01:21||2018-12-19 15:12|
|Target Version||Fixed in Version||4.08.0+dev|
|Summary||0007709: [Thread.sigmask] does not mask signals|
|Description||When using [Thread.sigmask] to mask signals in some thread (that is, to make sure that signals are received in one particular thread, for example), it seems like signals can be received even by threads for which signals are blocked.|
As an example, I join a test to the bug report. In that example, 3 computation-intensive threads are launched, and the signals are blocked for those. In the main thread, I unblock the signal and setup a signal handler that raises an exception. By catching the exception, I can determine which thread handled the signal. It seems like any thread can receive the signal.
By reading the runtime of OCaml, the cause of the bug seems easy to understand: The posix thread that receives the signal sets [caml_pending_signals], and then any thread can see this flag and run the OCaml handler.
I am not sure what is the best way to fix this issue:
(a) Have a per-thread [caml_pending_signals]. When the current thread is not executing, the signal handler should access thread local storage of the current thread to set [caml_pending_signals]. The same kind of idea applies for [caml_something_to_do]. The main problem I foresee is that we will have to setup a different handler when the [Thread] module is loaded or not.
(b) Before launching an OCaml handler, check that the signal is not blocked in the current thread. If it is, then we do not do anything and let another thread handle the signal. Then, we will have to change the implementation of [unix_sigpending] to take into account [caml_pending_signals]. Moreover, while signal is pending, each minor gc pass will trigger a call to [sigprocmask], and I am not sure this has actual negligible performance cost.
Moreover, I have no idea how this will interact with GPR#1128.
|Tags||No tags attached.|
|Attached Files||test2.ml [^] (1,337 bytes) 2018-01-14 01:21 [Show Content]|
|This bug is triggered in Coq: this makes the timeout tactic sometimes miss the SIGALRM signal, and hence not stopping the current tactic in time.|
This is a known issue since 2007 or so, see 0004127.
In its current state `Thread.sigmask` is basically useless. One can think of per-thread sets of pending signals and the like. But the POSIX thread semantics (deliver the async signal to any thread that doesn't block it) is questionable to begin with, so it's not clear to me we should invest efforts in reproducing the POSIX semantics in OCaml.
|Fixed in GPR#2104.|
|2018-01-14 01:21||jacques-henri.jourdan||New Issue|
|2018-01-14 01:21||jacques-henri.jourdan||File Added: test2.ml|
|2018-01-14 01:24||jacques-henri.jourdan||Note Added: 0018832|
|2018-01-14 11:01||xleroy||Relationship added||duplicate of 0004127|
|2018-01-14 11:05||xleroy||Note Added: 0018833|
|2018-01-14 11:05||xleroy||Severity||major => minor|
|2018-01-14 11:05||xleroy||Status||new => confirmed|
|2018-12-19 15:10||jacques-henri.jourdan||Assigned To||=> jacques-henri.jourdan|
|2018-12-19 15:10||jacques-henri.jourdan||Status||confirmed => assigned|
|2018-12-19 15:10||jacques-henri.jourdan||Status||assigned => resolved|
|2018-12-19 15:10||jacques-henri.jourdan||Fixed in Version||=> 4.08.0+dev|
|2018-12-19 15:10||jacques-henri.jourdan||Resolution||open => fixed|
|2018-12-19 15:12||jacques-henri.jourdan||Note Added: 0019510|
|Copyright © 2000 - 2011 MantisBT Group|