Proposal: new signal-handling API
Brandon S. Allbery KF8NH
allbery at ece.cmu.edu
Sat Jul 19 21:47:03 EDT 2008
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
More information about the Libraries
mailing list