GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2019-07-07T18:37:55Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/10017signal handlers are invoked multiple times when the threaded rts is used2019-07-07T18:37:55Zrednebsignal handlers are invoked multiple times when the threaded rts is usedWhen you install a custom signal handler and the threaded rts is being used, then the signal handler will be invoked multiple times. Here's a program that the demonstrates this:
```hs
import Control.Concurrent
import System.Posix.Signal...When you install a custom signal handler and the threaded rts is being used, then the signal handler will be invoked multiple times. Here's a program that the demonstrates this:
```hs
import Control.Concurrent
import System.Posix.Signals
main :: IO ()
main = do
_ <- flip (installHandler sig) Nothing $ Catch $
putStrLn $ "Received signal " ++ show sig
raiseSignal sig
threadDelay 100000
where
sig = sigUSR2
```
If you compile this with the `-threaded` flag and then run it with say `+RTS -N4` then it produces the following output:
```
Received signal 12
Received signal 12
Received signal 12
Received signal 12
Received signal 12
```
In general the signal handler is invoked `n_capabilities+1` times. This also happens with all other signals.
This regression was introduced by f9f89b7884ccc8ee5047cf4fffdf2b36df6832df (which was later \[changeset:4748f5936fe72d96edfa17b153dbfd84f2c4c053 reverted\] but then \[changeset:7e658bc14e2dd6baf208deebbdab9e1285ce4c72 re-added\]), a commit addressing #9423.
The cause of the problem is \[source:/rts/posix/Signals.c\@f44bbc83bab62f9a2d25e69d87c2b4af25318d52\#L256 this\] loop. I don't understand why we need to write an event about the signal received in the per capability control pipe introduced by the aforementioned commit. Aren't these control pipes supposed only to be used to shutdown the capabilities (which happens \[source:/rts/posix/Signals.c\@f44bbc83bab62f9a2d25e69d87c2b4af25318d52\#L183 here\])?
Removing the loop seems to solve the issue, but I don't know if it makes #9423 reappear. I cannot test this on a Mac OS X right now.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------------------ |
| Version | 7.10.1-rc1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Runtime System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | AndreasVoellmy, simonmar |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"signal handlers are invoked multiple times when the threaded rts is used","status":"New","operating_system":"","component":"Runtime System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"simonmar"},"version":"7.10.1-rc1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["AndreasVoellmy","simonmar"],"type":"Bug","description":"When you install a custom signal handler and the threaded rts is being used, then the signal handler will be invoked multiple times. Here's a program that the demonstrates this:\r\n\r\n{{{#!hs\r\nimport Control.Concurrent\r\nimport System.Posix.Signals\r\n\r\nmain :: IO ()\r\nmain = do\r\n _ <- flip (installHandler sig) Nothing $ Catch $\r\n putStrLn $ \"Received signal \" ++ show sig\r\n raiseSignal sig\r\n threadDelay 100000\r\n where\r\n sig = sigUSR2\r\n}}}\r\n\r\nIf you compile this with the `-threaded` flag and then run it with say `+RTS -N4` then it produces the following output:\r\n\r\n{{{\r\nReceived signal 12\r\nReceived signal 12\r\nReceived signal 12\r\nReceived signal 12\r\nReceived signal 12\r\n}}}\r\n\r\nIn general the signal handler is invoked `n_capabilities+1` times. This also happens with all other signals.\r\n\r\nThis regression was introduced by f9f89b7884ccc8ee5047cf4fffdf2b36df6832df (which was later [changeset:4748f5936fe72d96edfa17b153dbfd84f2c4c053 reverted] but then [changeset:7e658bc14e2dd6baf208deebbdab9e1285ce4c72 re-added]), a commit addressing #9423.\r\n\r\nThe cause of the problem is [source:/rts/posix/Signals.c@f44bbc83bab62f9a2d25e69d87c2b4af25318d52#L256 this] loop. I don't understand why we need to write an event about the signal received in the per capability control pipe introduced by the aforementioned commit. Aren't these control pipes supposed only to be used to shutdown the capabilities (which happens [source:/rts/posix/Signals.c@f44bbc83bab62f9a2d25e69d87c2b4af25318d52#L183 here])?\r\n\r\nRemoving the loop seems to solve the issue, but I don't know if it makes #9423 reappear. I cannot test this on a Mac OS X right now.","type_of_failure":"OtherFailure","blocking":[]} -->7.10.1AndreasVoellmyAndreasVoellmy