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 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by yquem.inria.fr (Postfix) with ESMTP id 97526BC6B for ; Tue, 28 Aug 2007 17:01:34 +0200 (CEST) Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.174]) by concorde.inria.fr (8.13.6/8.13.6) with ESMTP id l7SF1Xj2013955 for ; Tue, 28 Aug 2007 17:01:34 +0200 Received: from mac.com (smtpin04-en2 [10.13.10.149]) by smtpout.mac.com (Xserve/smtpout04/MantshX 4.0) with ESMTP id l7SF1WWB018029 for ; Tue, 28 Aug 2007 08:01:32 -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/smtpin04/MantshX 4.0) with ESMTP id l7SF1VWE024410 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 28 Aug 2007 08:01:32 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v752.2) In-Reply-To: <46D432CA.8010708@janestcapital.com> References: <9FA25C33-04DD-46BD-8959-873DDD2FFF82@epfl.ch> <1188055755.10796.37.camel@rosella.wigram> <1188257636.7533.23.camel@localhost.localdomain> <5EB9CEB2-3B79-4652-B6D1-10FEEC8E55E5@mac.com> <46D432CA.8010708@janestcapital.com> Content-Type: text/plain; charset=WINDOWS-1252; delsp=yes; format=flowed Message-Id: <486CE409-147C-4652-927F-B99ABFA9AC93@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 11:00:55 -0400 To: caml-list@inria.fr X-Mailer: Apple Mail (2.752.2) X-Miltered: at concorde with ID 46D438CD.000 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; runtime:01 runtime:01 threading:01 28,:98 2007,:98 wrote:01 wrote:01 executes:01 exception:01 exception:01 caml-list:01 computation:01 computation:01 treating:02 handler:03 On Aug 28, 2007, at 10:35, Brian Hurt wrote: > Gordon Henriksen wrote: > >> Such problems are too common to ignore. .NET defuses them by =20 >> treating 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, =20 >> but it will automatically be raised again at the end of the catch =20= >> block. When this exception is raised, the runtime executes all =20 >> the finally blocks before ending the thread. Since the thread can =20= >> do an unbounded computation in the finally blocks, or call =20 >> Thread.ResetAbort to cancel the abort, there is no guarantee that =20= >> the thread will ever end.=94 >> >> http://msdn2.microsoft.com/en-us/library/ =20 >> system.threading.threadabortexception.aspx > > So what happens if I throw an infinite loop into an exception handler? Such would fall into the category of =93unbounded computation=94 in the =20= quoted passage. =97 Gordon