> I had a look at the web interface to Caml's CVS repository
> and noticed that my previous patches are already incorporated
> (except for byterun/intern.c, but I'm not so sure that it makes
> a difference at all). :-)

I'm still not sure whether the casts are really needed or whether the
Dec C compiler is wrong in emitting a warning.

> I replaced all sigsetjmp() calls with _setjmp() calls (setjmp() is
> allowed to modify the signal mask, too, as per Single Unix Spec v2)
> and handled jumps out of signal handlers separately.

That's an interesting idea; I'll have to think about it.  By the way,
you can just do sigsetjmp(..., 0) if you don't want the signal mask to
be saved and restored; this is more portable than _setjmp.  

> 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".

Yes, asynchronous exceptions (such as those generated from a signal
handler) are very hard to use because of this.  The programming idiom
you showed above is safe for synchronous exceptions (exceptions that
can only be raised by "use resource"), however.

My take on this is that exceptions as they are implemented now are
just fine as a non-local control structure inside a sequential
program, but that something else is needed for multithreaded and
signal-based processing.  The thread cancellation model of Posix threads
is an interesting example of how inter-thread asynchronous
notifications can be made safe.

Regards,

- Xavier Leroy