Proposal: new signal-handling API

[Brandon S. Allbery KF8NH]

On 2008 Jul 19, at 21:30, Duncan Coutts wrote:

> On Sat, 2008-07-19 at 15:18 -0400, Brandon S. Allbery KF8NH wrote:
>> On 2008 Jul 19, at 13:07, Duncan Coutts wrote:
>>
>>> In particular the case of "I need to do this cleanup before the
>>> program
>>> terminates" is much more general than Posix and signals. For  
>>> example a
>>> library installing a handler for SIGINT is the wrong thing to do  
>>> (and
>>> not just because it's not very modular) but because the very  
>>> decision
>>> about whether SIGINT is going to kill the process or not is not for
>>> the
>>> library to decide. What it needs is to be thrown an exception when  
>>> the
>>> process does decide that it's going to terminate.
>>
>> ...and here you see why I made my proposal about mapping signals to
>> exceptions.
>
> Perhaps I misunderstood. I assumed you mean just a way of letting
> programs map signals to exceptions, which is something they can do

I may have spoken a bit too generically, but this is the essence of  
it:  sometimes when you receive a signal it wants to be handled as an  
exception, as with this.  Sometimes you want to handle interrupt/quit  
the same way; whether that is a good programming style or not may  
depend on what school of expression you come from.  Handling the  
common case of debug mechanisms hanging of of SIGUSR[12] is almost  
certainly a poor match with exceptions.

An example of when you might want to treat SIGINT as an example is a  
character-mode program with a user interface where you want to  
interrupt individual operations and return to the idle loop.   
(Consider yi as an example.)  If SIGINT is delivered to user code as  
an InterruptException then you simply wrap the command dispatcher in a  
catch.

Admittedly this is not necessarily easy in either case, and the code  
has to be ready to use critical sections or its own catch/rethrow to  
clean up resources.

> That way library code can just use ordinary exception handlers to  
> clean
> up and would not have to think about signals at all.


That's the idea, yes.  At this level a signal *is* a kind of  
exception, especially with respect to operations cleaning up after  
themselves.

-- 
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