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 5FF94BC6B for ; Tue, 28 Aug 2007 16:35:57 +0200 (CEST) Received: from smtp.janestcapital.com (www.janestcapital.com [66.155.124.107]) by concorde.inria.fr (8.13.6/8.13.6) with ESMTP id l7SEZtop005374 for ; Tue, 28 Aug 2007 16:35:56 +0200 Received: from [172.25.129.161] [38.96.172.125] by janestcapital.com with ESMTP (SMTPD-9.10) id A2E60650; Tue, 28 Aug 2007 10:36:22 -0400 Message-ID: <46D432CA.8010708@janestcapital.com> Date: Tue, 28 Aug 2007 10:35:54 -0400 From: Brian Hurt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Gordon Henriksen Cc: caml-list@inria.fr Subject: Re: [Caml-list] Has the thread cancellation problem evolved ? 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> In-Reply-To: <5EB9CEB2-3B79-4652-B6D1-10FEEC8E55E5@mac.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Miltered: at concorde with ID 46D432CB.001 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; runtime:01 runtime:01 threading:01 wrote:01 executes:01 exception:01 exception:01 caml-list:01 computation:01 treating:02 handler:03 library:03 brian:05 brian:05 problem:05 Gordon Henriksen wrote: > > Such problems are too common to ignore. .NET defuses them by treating > ThreadAbortException specially. > > “When a call is made to the Abort method to destroy a thread, the > common language runtime throws a ThreadAbortException. > ThreadAbortException is a special exception that can be caught, but > it will automatically be raised again at the end of the catch block. > When this exception is raised, the runtime executes all the finally > blocks before ending the thread. Since the thread can do an unbounded > computation in the finally blocks, or call Thread.ResetAbort to > cancel the abort, there is no guarantee that the thread will ever end.” > > http://msdn2.microsoft.com/en-us/library/ > system.threading.threadabortexception.aspx So what happens if I throw an infinite loop into an exception handler? Brian