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 (10:12)
From: Daniel_Bünzli <daniel.buenzli@e...>
Subject: Re: [Caml-list] Has the thread cancellation problem evolved ?

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.