Version française
Home     About     Download     Resources     Contact us    

This site is updated infrequently. For up-to-date information, please visit the new OCaml website at

Browse thread
Has the thread cancellation problem evolved ?
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2007-08-27 (12:24)
From: Daniel_Bünzli <daniel.buenzli@e...>
Subject: Re: [Caml-list] Has the thread cancellation problem evolved ?

Le 27 août 07 à 13:28, skaller a écrit :

> I agree with you rationale, but it isn't clear the conclusion follows
> that raise_in is acceptable.
> To give a simple pseudo code:
> 	begin
> 		let f = open_out filename in
> 		write f stuff;
> 		close f
> 	end
> which would work assuming write doesn't raise, will fail to
> work in the presence of async exceptions.

It won't fail to work, there is the possibility that f will never be  
closed, that's it. The point is that the code written above should  
not be written in a library (library IO routines should always take a  
channel or a stream, not a filename, for other reasons aswell, e.g.  
to IO on a socket). Such code should be written by the user of the  
library, and if he knows he needs to handle cancellation he will act  
accordingly. Note that you don't catch Sys_error here...

> This roughly means
> every resource acquisition MUST be guarded by a try/with
> which catches the async exception and releases the resource
> before re-raising it.

Yes but if you are not a sloppy programmer you already guard your  
operations on channels to handle the various errors that can occur  
and End_of_file. And if you are really not a sloppy programmer you  
already have and use your own version of try/finally :

let apply f x ~finally y =
   let res = try f x with exn -> finally y; raise exn in
   finally y;

Anyway most of the things I would like to cancel are not functions  
dealing with channels or locks but functions that do perform  
intensive numerical computations. In the presence of a human user you  
cannot let the ui hang for arbitrary long period of time, he should  
be able to cancel if he gets bored.