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 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from discorde.inria.fr (discorde.inria.fr [192.93.2.38]) by yquem.inria.fr (Postfix) with ESMTP id 81214BC6C for ; Mon, 27 Aug 2007 14:24:33 +0200 (CEST) Received: from mail12.bluewin.ch (mail12.bluewin.ch [195.186.19.61]) by discorde.inria.fr (8.13.6/8.13.6) with ESMTP id l7RCOXD0018125 for ; Mon, 27 Aug 2007 14:24:33 +0200 Received: from [10.0.1.2] (85.2.101.8) by mail12.bluewin.ch (Bluewin 7.3.121) id 46C9BD6300176B16 for caml-list@yquem.inria.fr; Mon, 27 Aug 2007 12:24:32 +0000 Mime-Version: 1.0 (Apple Message framework v752.2) In-Reply-To: <1188214119.13927.16.camel@rosella.wigram> References: <9FA25C33-04DD-46BD-8959-873DDD2FFF82@epfl.ch> <1188055755.10796.37.camel@rosella.wigram> <1188189497.11749.66.camel@rosella.wigram> <1188214119.13927.16.camel@rosella.wigram> Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <07BE0325-B260-407C-A1BB-389D4C88311C@epfl.ch> 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 14:24:34 +0200 To: caml-list@yquem.inria.fr X-Mailer: Apple Mail (2.752.2) X-Miltered: at discorde with ID 46D2C281.000 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; bunzli:01 buenzli:01 async:01 async:01 re-raising:01 exn:01 exn:01 computations:01 28,:98 aswell:98 exception:01 caml-list:01 functions:01 functions:01 exceptions:01 Le 27 ao=FBt 07 =E0 13:28, skaller a =E9crit : > 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 =3D 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. It won't fail to work, there is the possibility that f will never be =20 closed, that's it. The point is that the code written above should =20 not be written in a library (library IO routines should always take a =20= channel or a stream, not a filename, for other reasons aswell, e.g. =20 to IO on a socket). Such code should be written by the user of the =20 library, and if he knows he needs to handle cancellation he will act =20 accordingly. Note that you don't catch Sys_error here... > 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. Yes but if you are not a sloppy programmer you already guard your =20 operations on channels to handle the various errors that can occur =20 and End_of_file. And if you are really not a sloppy programmer you =20 already have and use your own version of try/finally : let apply f x ~finally y =3D let res =3D try f x with exn -> finally y; raise exn in finally y; res Anyway most of the things I would like to cancel are not functions =20 dealing with channels or locks but functions that do perform =20 intensive numerical computations. In the presence of a human user you =20= cannot let the ui hang for arbitrary long period of time, he should =20 be able to cancel if he gets bored. Daniel=