From: John Skaller <skaller@maxtal.com.au>
To: caml-list@inria.fr
Subject: Re: more patches (for Unix signal mask)
Date: Wed, 26 May 1999 01:16:23 +1000 [thread overview]
Message-ID: <3.0.6.32.19990526011623.00a6ac30@triode.net.au> (raw)
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
next prev parent reply other threads:[~1999-05-26 9:10 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
1999-05-16 21:40 Joerg Czeranski
1999-05-17 11:03 ` Are exceptions evil? (was: more patches) Joerg Czeranski
1999-05-18 1:25 ` UPDATE: more patches Joerg Czeranski
1999-05-18 16:10 ` more patches (for Unix signal mask) Xavier Leroy
1999-05-19 18:32 ` Joerg Czeranski
1999-05-25 15:16 ` John Skaller [this message]
1999-05-27 19:10 ` Xavier Leroy
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3.0.6.32.19990526011623.00a6ac30@triode.net.au \
--to=skaller@maxtal.com.au \
--cc=caml-list@inria.fr \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox