Browse thread
more patches (for Unix signal mask)
[
Home
]
[ Index:
by date
|
by threads
]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
| Date: | -- (:) |
| From: | John Skaller <skaller@m...> |
| Subject: | Re: more patches (for Unix signal mask) |
At 20:32 19/05/99 +0200, Joerg Czeranski wrote: >Maybe signals should be handled in a completely different way, >not via handlers, but as a special kind of input stream. Synchronous exceptions present enough difficulties without asychronous ones. A possible systemic difference is that while it is common to make synchronous exceptions equivalent to non-local gotos, that is, there's no retry, asynchronous exceptions should probably permit continuation. For example, after a keyboard interrupt, it often makes sense to complete some part of the current processing before responding; so the signal handler could set a flag which is polled at an appropriate place. So it is my guess that when a synchronous exception occurs, the stack should be unwound up to the handler, but for an asynchronous exception, the handler is invoked _without_ unwinding the stack. The handler has the choice os unwinding the stack, and thus making the signal act like a synchronous exception, or, continuing with the interrupted processing after changing state local to the handler which will cause a defered response to the signal, again synchronising the asynchronous event. In other words, no program can handle asynchonous events, they have to be synchonised with the normal control flow somehow, and the purpose of an asynchronous signal handling mechanism is to provide a choice of alternatives. We probably need the reverse too: a way to generate asynchronous exceptions. For example, a file operation which fails due to a hardware error which is reported with an error code could lead to generation of an asynchronous exception which is not normally caught an exception handler. Local synchronous handlers can be designed to handle end-of-file conditions, but hardware errors might require a different kind of processing, such as 'Please put the CD-ROM back in the drive!!' :-) ------------------------------------------------------- John Skaller email: skaller@maxtal.com.au http://www.maxtal.com.au/~skaller phone: 61-2-96600850 snail: 10/1 Toxteth Rd, Glebe NSW 2037, Australia