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 concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by yquem.inria.fr (Postfix) with ESMTP id 6B4BABC6B for ; Mon, 27 Aug 2007 16:27:57 +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 l7RERt01030946 for ; Mon, 27 Aug 2007 16:27:56 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAKt60kY7pw2h/2dsb2JhbAAM X-IronPort-AV: E=Sophos;i="4.19,311,1183300200"; d="scan'208";a="180534866" 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 23:57:53 +0930 Subject: Re: [Caml-list] Has the thread cancellation problem evolved ? From: skaller To: Jon Harrop Cc: caml-list@yquem.inria.fr In-Reply-To: <200708271338.51566.jon@ffconsultancy.com> References: <9FA25C33-04DD-46BD-8959-873DDD2FFF82@epfl.ch> <1188214119.13927.16.camel@rosella.wigram> <07BE0325-B260-407C-A1BB-389D4C88311C@epfl.ch> <200708271338.51566.jon@ffconsultancy.com> Content-Type: text/plain Date: Tue, 28 Aug 2007 00:27:51 +1000 Message-Id: <1188224871.17423.7.camel@rosella.wigram> Mime-Version: 1.0 X-Mailer: Evolution 2.10.1 Content-Transfer-Encoding: 7bit X-Miltered: at concorde with ID 46D2DF6B.001 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; 0100,:01 compiler:01 async:01 allocating:01 ocaml:01 model:01 sourceforge:01 wrote:01 ideally:01 caml-list:01 exceptions:01 arbitrary:02 encoding:02 cps:02 seems:03 On Mon, 2007-08-27 at 13:38 +0100, Jon Harrop wrote: > In the presence of a human user you > > cannot let the ui hang for arbitrary long period of time, he should > > be able to cancel if he gets bored. > > Then write in CPS and weave an abortable continuation between each step. But there's no assurance that will work: Felix uses a closely related technique involving resumptions, but the compiler also optimises almost every one of those 'steps' away. Encoding regular checks is too hard; in that Daniel is right the user shouldn't have to bother. However a compromise might be: in most code, block async exceptions, at specified points, do a check. In computationally intensive code not allocating resources, allow them anywhere and guard with a single trap. Well .. this reminds me of the problem of scheduling parallel processing .. skeletons and Ocaml3p come to mind here. It seems in this model type system support is required: ideally the 'guarded intensive calculation' would be a monad? -- John Skaller Felix, successor to C++: http://felix.sf.net