Message-Id: <3.0.6.32.19990526011623.00a6ac30@triode.net.au>
Date: Wed, 26 May 1999 01:16:23 +1000
To: caml-list@inria.fr
From: John Skaller <skaller@maxtal.com.au>
Subject: Re: more patches (for Unix signal mask)
In-Reply-To: <5vbM3S6mM$17V$1@joerch.org>
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
This archive was generated by hypermail 2b29 : Sun Jan 02 2000 - 11:58:22 MET