Are exceptions evil? (was: more patches)

From: Joerg Czeranski (jc@joerch.org)
Date: Mon May 17 1999 - 13:03:28 MET DST


From: Joerg Czeranski <jc@joerch.org>
To: caml-list@inria.fr
In-Reply-To: <5v6tgd6vv$19X$1@joerch.org>
Date: Mon, 17 May 1999 13:03:28 +0200 (MET DST)
Subject: Are exceptions evil? (was: more patches)

This morning I rethought my patches under the shower and found another
bug (signals are not blocked while the handler is executed, if the
signal was caught with async_signal_mode == 0).

It's not difficult to fix, I'll do that later. Even the signal
loss race condition can be fixed without too much thought.

But that's because signals are easy to control, they move down the
stack (for stacks growing down). They won't bypass interrupted
functions, they only return to them after being handled.

Exceptions on the other hand go straight up the stack until they find
a handler, and then *immediately* invalidate the handler.
In a non-pure programming language like O'Caml this creates unavoidable
race conditions:

        let resource = acquire () in
        try
                use resource;
                release resource
        with e ->
                release resource;
                raise e

"release" is never called if two exceptions arrive at virtually
the same time, and neither if an exception arrives after the call
to "acquire", but before the "try".

N.b.: For me acquire is usually Unix.openfile, but it could as well
be a native O'Caml function with sideeffects (like "incr semaphore").

I think the fundamental reason for this problem is that exceptions
are thrown up the stack and not forward on the timeline of side effects.
They ought to skip new acquire calls, but never a release call for
a resource already acquired.

Is there anything that can be done about this? Or does it require
wrapping all (relevant) side effects with monads? Or am I missing
something?

regards,
joerch



This archive was generated by hypermail 2b29 : Sun Jan 02 2000 - 11:58:22 MET