Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0007709OCamlthreadspublic2018-01-14 01:212018-12-19 15:12
Assigned Tojacques-henri.jourdan 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version4.08.0+dev 
Summary0007709: [Thread.sigmask] does not mask signals
DescriptionWhen 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.
TagsNo tags attached.
Attached Files? file icon [^] (1,337 bytes) 2018-01-14 01:21 [Show Content]

- Relationships
duplicate of 0004127resolvedjacques-henri.jourdan Thread.sigmask not working under pthreads 

-  Notes
jacques-henri.jourdan (manager)
2018-01-14 01:24

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.
xleroy (administrator)
2018-01-14 11:05

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.
jacques-henri.jourdan (manager)
2018-12-19 15:12

Fixed in GPR#2104.

- Issue History
Date Modified Username Field Change
2018-01-14 01:21 jacques-henri.jourdan New Issue
2018-01-14 01:21 jacques-henri.jourdan File Added:
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
Powered by Mantis Bugtracker