Re: [Caml-list] Has the thread cancellation problem evolved ?

["Daniel Bünzli" <daniel.buenzli@epfl.ch>]

Le 27 août 07 à 06:38, skaller a écrit :

> That is a reasonable crude idea, but not precise because you haven't
> specified what 'should' happen to any acquired resources which would
> normally be released under program control.

They are left as is. If the programmer didn't care to handle, this is  
his problem, as when he forgets to close a file. The problem is if  
you don't even give the opportunity to the programmer to handle the  
problem, this is why Thread.kill is bad but Thread.raise_in acceptable.

> I cannot agree with that claim at this time. If a library
> acquires resources and should support cancellation, then the library
> must also make provision for relinquishing those resources,
> including on cancellation.

I think that in gc'd environment this problem is less acute. How many  
of the libraries out there are using locks or do fd business I don't  
know _under_ the module interface ? Any library that does not perform  
that kind of thing, and to overapproximate that does not bind to C,  
won't have a problem with cancellation. If their resource usage is  
explicit then I'm writing the resources allocation and deallocation  
and my thread will release them in the exception handler that I will  
write. I'll design and care for it.

Daniel