FFI: Problem with Signal Handler Interruptions
Apologies for re-posting this subject here since I had sent already a message to haskell-café 3 days ago, but I just learned about this mailing list and it seems more appropriate to ask this question here I guess. I already got a reply from Simon Marlow but I posted some further (so far unanswered) questions. The thread starts here: http://www.haskell.org//pipermail/haskell-cafe/2009-August/064880.html. Basically my remaining questions are: 1. How can one safely perform a blocking wait on a system call via FFI when compiling with -threaded and avoid signal interruptions which cause the call to return with EINTR? 2. Could 1. be achieved by blocking SIGVTALRM in the thread doing the call? For details please cf. the original maling list thread. Many thanks, Levi
Hello Levi, Friday, August 7, 2009, 6:48:42 PM, you wrote:
1. How can one safely perform a blocking wait on a system call via FFI when compiling with -threaded
i think you should use forkOS to create OS thread dedicated to Haskell thread
and avoid signal interruptions which cause the call to return with EINTR?
don't know, but may be you can retry on this retcode or disable EINTR in one specific OS thread -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com
Hi Bulat,
On Fri, Aug 7, 2009 at 5:32 PM, Bulat
Ziganshin
Hello Levi,
Friday, August 7, 2009, 6:48:42 PM, you wrote:
1. How can one safely perform a blocking wait on a system call via FFI when compiling with -threaded
i think you should use forkOS to create OS thread dedicated to Haskell thread
Yes, but that wouldn't help me with my problem of getting signal interruptions. Simon Marlow wrote in the haskell-café thread: "The SIGVTALRM signal is delivered to one (random) thread in the program [...]" [1]
and avoid signal interruptions which cause the call to return with EINTR?
don't know, but may be you can retry on this retcode or disable EINTR in one specific OS thread
Yes, currently I use throwErrnoIfMinus1Retry from Foreign.C.Error, but I am not sure if this is the recommended way. Seeing ... rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0 rt_sigaction(SIGCHLD, NULL, {SIG_DFL}, 8) = 0 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0 nanosleep({3, 0}, 0xbfad005c) = ? ERESTART_RESTARTBLOCK (To be restarted) --- SIGVTALRM (Virtual timer expired) @ 0 (0) --- sigreturn() = ? (mask now []) ... many times in the output of strace made me slightly uneasy. So right now I have two options which *seem* to work ok. One is to retry on EINTR, and the other to block SIGVTALRM as described in [2]. But am still unsure whether (i) this is correct and recommended, and (ii) there is no better option. Cheers, Levi --- [1] http://www.haskell.org//pipermail/haskell-cafe/2009-August/064971.html [2] http://www.haskell.org//pipermail/haskell-cafe/2009-August/065023.html
Bulat Ziganshin wrote:
Hello Levi,
Friday, August 7, 2009, 6:48:42 PM, you wrote:
1. How can one safely perform a blocking wait on a system call via FFI when compiling with -threaded
i think you should use forkOS to create OS thread dedicated to Haskell thread
Why do you recommend forkOS here? forkOS is normally only necessary if you need to access thread-local state in the C call. Cheers, Simon
Levi Greenspan wrote:
Apologies for re-posting this subject here since I had sent already a message to haskell-café 3 days ago, but I just learned about this mailing list and it seems more appropriate to ask this question here I guess. I already got a reply from Simon Marlow but I posted some further (so far unanswered) questions. The thread starts here: http://www.haskell.org//pipermail/haskell-cafe/2009-August/064880.html. Basically my remaining questions are:
1. How can one safely perform a blocking wait on a system call via FFI when compiling with -threaded and avoid signal interruptions which cause the call to return with EINTR?
You should check for EINTR and restart the call as necessary. This is standard best practice for POSIX programming anyway, and we do it for all the calls that can return EINTR in the IO library and RTS.
2. Could 1. be achieved by blocking SIGVTALRM in the thread doing the call?
Blocking SIGVTALRM is not a good idea: the RTS relies on the signal for various things. Cheers, Simon
On Fri, Aug 14, 2009 at 11:45 PM, Simon Marlow
You should check for EINTR and restart the call as necessary. This is standard best practice for POSIX programming anyway, and we do it for all the calls that can return EINTR in the IO library and RTS. [...] Blocking SIGVTALRM is not a good idea: the RTS relies on the signal for various things.
Alright. I'll do it this way then. Many thanks for your advice. Cheers, Levi
participants (3)
-
Bulat Ziganshin -
Levi Greenspan -
Simon Marlow