[mercury-users] Exceptions and unique modes

Ralph Becket rbeck at microsoft.com
Fri Feb 16 20:36:42 AEDT 2001


>From Richard A. O'Keefe on 15/02/2001 22:44:14
>[...much that I agree with...]

At first I found myself wishing for exceptions to deal with error cases
when handling IO, but I no longer believe that is the right way to go.
I still have to check for EOF on every read, so why not errors as well?
Putting exception handlers in starts to look like more and more hassle.

> I think there is ONE place where "has to be able to survive unexpected
> exceptions" is true, and that is where a program loads more code at
> run time and has good reason not to trust it.  I met this in a student
> Algol compiler at the University of Auckland.  It's one of the reasons
> why Java has exceptions, and one of the reasons why Quintus Prolog has
> them.

I can think of two other places where they might be needed:
1. when a rarely used component in a program fails, the rest of the 
application (for many domains, e.g. a webserver) should have some
opportunity to try to recover;
2. when a trusted component in a program fails (e.g. runs out of
memory.)

There are other types of event that are similar to exceptions such as
a thread receiving a timeout or a termination signal from another
thread or the user hitting ^C etc.

Thinking about it, handling these kinds of events is the sort of thing
that can be done with thread scheduler activations (see e.g. the 
Nemesis operating system
http://nemesis.sourceforge.net/structure/index.html).

The idea behind activations is that a process consists of one or more
schedulers and an activation handler.  Event messages are delivered
asynchronously to a queue for the handler, which is run every
time the process is handed the CPU by the OS.  The handler is responsible
for scheduling the threads and delivering messages to the thread message
queues.  The handler can also make policy decisions such as what to do
when a particular thread falls over for some reason (kill it, restart it,
clean up, inform other threads and processes etc.)  The power of the
Nemesis model was that the activation handler could be written by the
programmer rather than being part of the OS.

--
Ralph Becket      |      MSR Cambridge      |      rbeck at microsoft.com 

--------------------------------------------------------------------------
mercury-users mailing list
post:  mercury-users at cs.mu.oz.au
administrative address: owner-mercury-users at cs.mu.oz.au
unsubscribe: Address: mercury-users-request at cs.mu.oz.au Message: unsubscribe
subscribe:   Address: mercury-users-request at cs.mu.oz.au Message: subscribe
--------------------------------------------------------------------------



More information about the users mailing list