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 concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by yquem.inria.fr (Postfix) with ESMTP id EB77BBC6B for ; Mon, 27 Aug 2007 13:28:44 +0200 (CEST) Received: from ipmail01.adl2.internode.on.net (ipmail01.adl2.internode.on.net [203.16.214.140]) by concorde.inria.fr (8.13.6/8.13.6) with ESMTP id l7RBSgNh005537 for ; Mon, 27 Aug 2007 13:28:44 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAADJN0kY7pw2h/2dsb2JhbAAM X-IronPort-AV: E=Sophos;i="4.19,311,1183300200"; d="scan'208";a="180438776" Received: from ppp59-167-13-161.lns2.syd7.internode.on.net (HELO [192.168.1.201]) ([59.167.13.161]) by ipmail01.adl2.internode.on.net with ESMTP; 27 Aug 2007 20:58:40 +0930 Subject: Re: [Caml-list] Has the thread cancellation problem evolved ? From: skaller To: Daniel =?ISO-8859-1?Q?B=FCnzli?= Cc: caml-list@yquem.inria.fr In-Reply-To: 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=utf-8 Date: Mon, 27 Aug 2007 21:28:39 +1000 Message-Id: <1188214119.13927.16.camel@rosella.wigram> Mime-Version: 1.0 X-Mailer: Evolution 2.10.1 Content-Transfer-Encoding: 8bit X-Miltered: at concorde with ID 46D2B56A.000 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; 0200,:01 async:01 async:01 re-raising:01 constructors:01 pointers:01 ocaml:01 monadic:01 gc'd:01 deallocation:01 allocating:01 allocations:01 hofs:01 sourceforge:01 garbage:01 On Mon, 2007-08-27 at 12:12 +0200, Daniel Bünzli wrote: > 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 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. 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. With a simple stack protocol this is fine .. but we use the heap and garbage collectors because the stack isn't enough, so presumably this protocol could be hard to follow. In C++, RAIII is used for this, i.e. object whose constructors acquire a resource and destructors release it, together with say ref counted pointers, so that throwing an exception unwinds all the objects, i.e. executes the destructors to release the resources. Ocaml has no such facility. SO before even considering raise_in you need to propose one: possibly this would involve a monadic programming style, but I don't really know. I would guess, adding async exceptions, plus a requirement to properly manage resources, could have a radical impact on acceptable library designs. Please note this is a guess. I don't know. But I think before even asking for async exception, you'd need at least one proposal to handle them. > > 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. That may be so, on the assumption calls to the gc are frequent, which sounds fairly reasonable to me. > 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. It is not so simple I suspect .. you can put an exception handler at the start of the thread, but then how do you know what resources to release? If there is a registry of them .. all the routine allocating resources must use the registry. The problem is try/raise/with is a stack protocol: you cannot wrap allocations in it, if the allocation returns the resource. I'm not saying there is no solution.. but if you have libraries, particularly ones with HOFs, then you have to actually have a standardised protocol that all the libraries have to follow. -- John Skaller Felix, successor to C++: http://felix.sf.net