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=none 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 1B081BC6B for ; Mon, 27 Aug 2007 09:43:19 +0200 (CEST) Received: from server2.thinkcrime.de (server2.thinkcrime.de [213.133.110.149]) by concorde.inria.fr (8.13.6/8.13.6) with ESMTP id l7R7hI1m007510 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 27 Aug 2007 09:43:18 +0200 Received: from hod-sarge-2005-10.lan.m-e-leypold.de (dslb-088-072-238-104.pools.arcor-ip.net [88.72.238.104]) (Authenticated sender: hod-sarge-2005-10@server2) by server2.thinkcrime.de (Postfix) with ESMTP id 638BB90015D for ; Mon, 27 Aug 2007 09:43:09 +0200 (CEST) Received: by hod-sarge-2005-10.lan.m-e-leypold.de (Postfix, from userid 1003) id 5DC4037BD0; Mon, 27 Aug 2007 09:55:24 +0200 (CEST) To: 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> From: Markus E L Organization: N/A Date: Mon, 27 Aug 2007 09:55:24 +0200 In-Reply-To: ( =?iso-8859-1?q?Daniel_B=FCnzli's_message_of?= "Mon, 27 Aug 2007 01:47:42 +0200") Message-ID: User-Agent: Some cool user agent (SCUG) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Miltered: at concorde with ID 46D28096.000 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; markus:01 bunzli:01 ocaml:01 runtime:01 computations:01 computations:01 marshalling:01 markus:01 band:98 invoke:01 wrote:01 caml-list:01 computation:01 data:02 width:97 Daniel B=FCnzli wrote: > Le 25 ao=FBt 07 =E0 17:29, skaller a =E9crit : > >> There is something I don't understand here. > > What you don't understand is that ocaml has a runtime system which > leaves some room for designing around what exists at the os level. > >> If the source of the problem is a blocking operation, the solution >> is simple: don't use blocking operations! > > This is not the source of the problem. What I want is to allow users > to initiate and cancel computations whenever they want. Computations > can be lengthy even tough they do not invoke a blocking operation. I'm sure the approach I'm suggesting might be too simple, perhaps you even have thought about it and it doesn't meet your demands: But have you thought about doing the users computation in a fork()ed child process and communicate the result(s) back by marshalling over a pipe? The communication band width after forking is limited (but the child process has all the data of the parent process at the time of the fork()). On the other side it would solve the (a) code unloading problem and (b) the cancellation every time problem (you can always cancel by sending as SIGKILL :-). Regards -- Markus