[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: exception systems



|   Date: Thu, 18 Apr 1996 13:35:16 -0400
|   From: Olin Shivers <shivers@lambda.ai.mit.edu>
|   Cc: rrrs-authors@mc.lcs.mit.edu, kmp@harlequin.com, gjr@martigny.ai.mit.edu
|   Reply-To: shivers@ai.mit.edu

|   I would like to take a stand against referring to async interrupts as
|   exceptions.  I'd like to retain the word "exceptions" as meaning something
|   synchronous -- the result of something my program did at a particular point,
|   e.g. "I added those two numbers together and it blew up on me." Not something
|   that could be caused by an external agent, completely independent of what my
|   program was doing.
|
|   (Synchronous) Exceptions are just extra edges in your control-flow
|   graph. Asynchronous signals are a communications mechanism between concurrent
|   agents (in Unix, processes). The machinery appropriate for these two types of
|   thing is not the same.
|
|   I hate the fact that Unix confounds these two concepts, and would like to
|   avoid doing it in Scheme.

Gee, for once I agree with Olin :-)

Although I view synchronous faults (whether raised by hardware or
software) and asynchronous interrupts very differently, it is
convenient occasionally to handle them uniformly.

For example, timer interrupts can be used to switch contexts but also
to abort a potentially-blocking operation.  In the first use it is
hard to see them as exceptions, while in the second it is very natural.

I suspect that you still agree with the basic requirements that would
allow asynchronous events to be reflected onto the exception mechanism
_if desired_, even if not mandated.

I also agree with Will that we should concentrate on exceptions now,
but would like to explore in the future the possibility of a
standardized asynchronous delivery mechanism, especially for timer
events/interrupts.