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@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH