From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=AWL autolearn=disabled version=3.1.3 Received: from discorde.inria.fr (discorde.inria.fr [192.93.2.38]) by yquem.inria.fr (Postfix) with ESMTP id B4CCDBC6C for ; Mon, 27 Aug 2007 12:12:52 +0200 (CEST) Received: from mail16.bluewin.ch (mail16.bluewin.ch [195.186.19.63]) by discorde.inria.fr (8.13.6/8.13.6) with ESMTP id l7RACqZY020944 for ; Mon, 27 Aug 2007 12:12:52 +0200 Received: from [10.0.1.2] (85.2.101.8) by mail16.bluewin.ch (Bluewin 7.3.121) id 46C9BEAD001747A7 for caml-list@yquem.inria.fr; Mon, 27 Aug 2007 10:12:52 +0000 Mime-Version: 1.0 (Apple Message framework v752.2) In-Reply-To: <1188189497.11749.66.camel@rosella.wigram> References: <9FA25C33-04DD-46BD-8959-873DDD2FFF82@epfl.ch> <1188055755.10796.37.camel@rosella.wigram> <1188189497.11749.66.camel@rosella.wigram> Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: =?ISO-8859-1?Q?Daniel_B=FCnzli?= Subject: Re: [Caml-list] Has the thread cancellation problem evolved ? Date: Mon, 27 Aug 2007 12:12:53 +0200 To: caml-list@yquem.inria.fr X-Mailer: Apple Mail (2.752.2) X-Miltered: at discorde with ID 46D2A3A4.001 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; bunzli:01 buenzli:01 gc'd:01 deallocation:01 exception:01 caml-list:01 epfl:02 module:03 handler:03 library:03 library:03 raise:03 locks:03 explicit:04 daniel:04 Le 27 ao=FBt 07 =E0 06:38, skaller a =E9crit : > 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 =20= his problem, as when he forgets to close a file. The problem is if =20 you don't even give the opportunity to the programmer to handle the =20 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 =20= of the libraries out there are using locks or do fd business I don't =20 know _under_ the module interface ? Any library that does not perform =20= that kind of thing, and to overapproximate that does not bind to C, =20 won't have a problem with cancellation. If their resource usage is =20 explicit then I'm writing the resources allocation and deallocation =20 and my thread will release them in the exception handler that I will =20 write. I'll design and care for it. Daniel=