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.1 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 817BBBC6B for ; Tue, 28 Aug 2007 16:24:23 +0200 (CEST) Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.175]) by concorde.inria.fr (8.13.6/8.13.6) with ESMTP id l7SEOMVS000783 for ; Tue, 28 Aug 2007 16:24:22 +0200 Received: from mac.com (smtpin08-en2 [10.13.10.153]) by smtpout.mac.com (Xserve/smtpout05/MantshX 4.0) with ESMTP id l7SEOLSf014824 for ; Tue, 28 Aug 2007 07:24:21 -0700 (PDT) Received: from [192.168.8.101] (c-24-218-151-219.hsd1.ma.comcast.net [24.218.151.219]) (authenticated bits=0) by mac.com (Xserve/smtpin08/MantshX 4.0) with ESMTP id l7SEOK2f014887 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 28 Aug 2007 07:24:21 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v752.2) In-Reply-To: References: <9FA25C33-04DD-46BD-8959-873DDD2FFF82@epfl.ch> <1188055755.10796.37.camel@rosella.wigram> <1188257636.7533.23.camel@localhost.localdomain> Content-Type: text/plain; charset=WINDOWS-1252; delsp=yes; format=flowed Message-Id: <5EB9CEB2-3B79-4652-B6D1-10FEEC8E55E5@mac.com> Content-Transfer-Encoding: quoted-printable From: Gordon Henriksen Subject: Re: [Caml-list] Has the thread cancellation problem evolved ? Date: Tue, 28 Aug 2007 10:23:43 -0400 To: caml-list@inria.fr X-Mailer: Apple Mail (2.752.2) X-Miltered: at concorde with ID 46D43016.000 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; bunzli:01 gerd:01 stolpmann:01 runtime:01 runtime:01 threading:01 28,:98 2007,:98 26,:98 wrote:01 executes:01 exception:01 exception:01 caml-list:01 computation:01 On Aug 28, 2007, at 05:26, Daniel B=FCnzli wrote: > Le 28 ao=FBt 07 =E0 01:33, Gerd Stolpmann a =E9crit : > >> Nevertheless, I don't think this is a good thing. Raising an =20 >> exception at potentially any moment is a problematic thing. E.g. =20 >> code like >> >> let x =3D try Some(List.assoc ... with _) -> None >> >> where the author implicitly assumes that it is only Not_found that =20= >> can happen and the code is just plain wrong if anything else is =20 >> encoded into the exception. > > But this is sloppy programming anyway. The author is plain wrong in =20= > assuming that only Not_found can be raised, he is asking for a =20 > potential time consuming debugging session. Such problems are too common to ignore. .NET defuses them by treating =20= ThreadAbortException specially. =93When a call is made to the Abort method to destroy a thread, the =20 common language runtime throws a ThreadAbortException. =20 ThreadAbortException is a special exception that can be caught, but =20 it will automatically be raised again at the end of the catch block. =20 When this exception is raised, the runtime executes all the finally =20 blocks before ending the thread. Since the thread can do an unbounded =20= computation in the finally blocks, or call Thread.ResetAbort to =20 cancel the abort, there is no guarantee that the thread will ever end.=94 http://msdn2.microsoft.com/en-us/library/=20 system.threading.threadabortexception.aspx =97 Gordon