From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from weis@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id LAA11355 for caml-redistribution; Wed, 26 May 1999 11:10:21 +0200 (MET DST) Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id RAA03581 for ; Tue, 25 May 1999 17:20:32 +0200 (MET DST) Received: from iggy.triode.net.au ([203.63.235.1]) by nez-perce.inria.fr (8.8.7/8.8.7) with ESMTP id RAA12622 for ; Tue, 25 May 1999 17:20:27 +0200 (MET DST) Received: from egret (pm1-2.triode.net.au [203.63.235.18]) by iggy.triode.net.au (8.8.8/8.8.8) with SMTP id BAA29784 for ; Wed, 26 May 1999 01:20:25 +1000 Message-Id: <3.0.6.32.19990526011623.00a6ac30@triode.net.au> X-Sender: skaller@triode.net.au X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32) Date: Wed, 26 May 1999 01:16:23 +1000 To: caml-list@inria.fr From: John Skaller Subject: Re: more patches (for Unix signal mask) In-Reply-To: <5vbM3S6mM$17V$1@joerch.org> References: <19990518181020.A24993@hoedic.trusted-logic.fr> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: weis 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