Browse thread
Has the thread cancellation problem evolved ?
[
Home
]
[ Index:
by date
|
by threads
]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
[ 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. Daniel