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

Re: Poison



I think Ian East has made a very important point -
 
>If added to any language, I'd hope for a mapping back to
>existing constructs.

Thus, there can be two levels (and this is very well
adapted to "experimental" too): the simple old-fashioned
occam (aided, possibly by Transputer developed "real"
substructure), to which Occam's razor always applies;
and the "programmer friendly" superstructure which can
always be formally proved to be equivalent. 

A lot of CPU cycles can be saved that way!

Larry Dickson

>From owner-occam-com-out@xxxxxxxxx Thu Jul 26 08:31:27 2001
Subject: Re: Poison
Date: Thu, 26 Jul 01 16:30:49 +0100
x-sender: ianeast+akela@xxxxxxxxxxxxxx
x-mailer: Claris Emailer 2.0v2, June 6, 1997
From: ianeast <ianeast@xxxxxxxxxxxxxxx>
To: "A E Lawrence" <adrian.lawrence@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>,
   "Peter Welch" <P.H.Welch@xxxxxxxxx>
cc: <java-threads@xxxxxxxxx>, <mboosten@xxxxxxxxxxxxxxxxxxx>,
   <occam-com@xxxxxxxxx>
Mime-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Precedence: bulk

My 4p worth...
Must remind myself of what the great CARH had to say about interruption, 
but I agree with Marcel's comments regarding the real world. I've always 
based my CPA teaching on things like building sites (following Fox), 
better still natural systems. The need to respond to (shared) events with 
different degrees of priority is unavoidable in reality.
  In my view, the only case for exception-handling in programs is to 
avoid repetitive and tedious clutter. But that's a strong case. If added 
to any language, I'd hope for a mapping back to existing constructs.
  Unless I'm misunderstanding something, our priority should be priority. 
I believe priority must associate with events, and not processes. An 
exception is just a high-priority event. In occam, priority may not be 
agreed by two communicating processes, and is static (in reality it can 
change).

A _real_ process must respond to error. Any finite system can suffer 
overflow, for example. Such events should be predefined. The process must 
then be capable of resetting, or terminating, the entire system (or just 
the subset of processes within the current "atomic action"). I like the 
idea of having Peter's poison algorithm built-in, but only as an option. 
I want WYSIWYG code.

I gather the default exception response in a typical engine management 
unit is to turn off the engine. Let's hope the process responsible for 
"electronic brake distribution" doesn't turn off the brakes.

How about a dedicated "beer and sandwiches" lunch-time session on this in 
Bristol?

Ian East

Dr. Ian Robert East         School of Computing and Mathematical Sciences
ireast@xxxxxxxxxxxxx                            Oxford Brookes University
(44) 1865 483635                                           Oxford OX3 0BP

Consultation hours for 2001/2002 Term 1
To be decided