Proposal: new signal-handling API

[Brandon S. Allbery KF8NH]

On 2008 Jul 18, at 11:45, John Goerzen wrote:

> It could also be important if you really don't want other signals  
> handlers doing anything.  Say you've got a library that installs a  
> handler for SIGINT that flushes out some buffer and prepares things  
> for the progam to terminate nicely.  But in a certain part of your  
> code, you don't want to handle SIGINT at all (or you absolutely want  
> it to be handled only by saying putStrLn "Don't press Ctrl-C now,  
> you dolt!"). Since adding a signal handler could be opaque, this  
> could be quite difficult.  With the proposed system, you never know  
> if some module has installed a signal handler, which could be an  
> issue in itself.

This is where you use sigprocmask() in POSIX to simply disallow the  
signal during your critical section; safer than trusting the user not  
to interrupt.  Your earlier example could be handled by pushing/ 
popping handlers (and I imagine a typesafe way of doing both of these,  
e.g. withSignalHandlerDo signal handler block / withSignalMaskDo mask  
block).

-- 
brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery at kf8nh.com
system administrator [openafs,heimdal,too many hats] allbery at ece.cmu.edu
electrical and computer engineering, carnegie mellon university    KF8NH