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;
   res

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.

Daniel