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 68C44BC69 for ; Sat, 25 Aug 2007 17:29:21 +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 l7PFTJg1029791 for ; Sat, 25 Aug 2007 17:29:20 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAH7lz0Y7pw2h/2dsb2JhbAAM X-IronPort-AV: E=Sophos;i="4.19,307,1183300200"; d="scan'208";a="179323495" 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; 26 Aug 2007 00:59:17 +0930 Subject: Re: [Caml-list] Has the thread cancellation problem evolved ? From: skaller To: Daniel =?ISO-8859-1?Q?B=FCnzli?= Cc: caml-list@yquem.inria.fr In-Reply-To: <9FA25C33-04DD-46BD-8959-873DDD2FFF82@epfl.ch> References: <9FA25C33-04DD-46BD-8959-873DDD2FFF82@epfl.ch> Content-Type: text/plain; charset=utf-8 Date: Sun, 26 Aug 2007 01:29:15 +1000 Message-Id: <1188055755.10796.37.camel@rosella.wigram> Mime-Version: 1.0 X-Mailer: Evolution 2.10.1 Content-Transfer-Encoding: 8bit X-Miltered: at concorde with ID 46D04ACF.000 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; 0200,:01 afaik:01 gerd:01 stolpmann:01 bug:01 ocaml:01 ocaml:01 interfacing:01 monadic:01 combinator:01 computations:01 destroying:98 invoke:01 threads:01 sourceforge:01 On Sat, 2007-08-25 at 15:58 +0200, Daniel Bünzli wrote: > Hello everybody, > > I would like to raise again the problem of portable thread > cancellation. There is something I don't understand here. Thread cancellation is a function of the native operating system. You mention > Thread cancellation allows to invoke an arbitrary function f on a > thread and stop its execution before completion, and no operating system I know supports that. Posix, for example allows cancelling a thread ONLY at specified system calls, typically blocking socket related ones. It also misses one critical one (I forget which). The only other way to cancel a thread on Posix is to send a signal and AFAIK there is no standardised signal to do that (only for processes?) So you're asking Xavier to implement something impossible. It can't be done in native code in the first place, forget about safely. Futhermore: > [5] by Gerd Stolpmann is > portable. Note however that neither solution will work with > uncooperative threads, i.e. those that never perform any system call > or trigger the gc [7]. And it is almost certainly not portable. Portable means on ALL operating systems .. including Windows. > I would appreciate having "Thread.raise_in" implemented, with the > system call caveat properly documented, instead of having to resort > to [5]. There is no feature request about this in the bug tracker. > Before filling a potentially useless one I would like to know what > you think about these problems and if there are things I have missed. The general solution to this problem is to kill the whole process. This ensures resources are cleaned up at the OS level, if not the user level. BTW: you can say "this isn't feasible for a web server" and I can reply "No, and neither is destroying a thread out of the thread pool". Otherwise, somewhere somehow there has to be a check done: whether it is by the OS, by the Ocaml gc, or some user function. Throwing an Ocaml exception is a very bad idea as a response! It isn't just that resources won't be cleaned up .. it could happen in the middle of C code interfacing Ocaml, and leave the whole process in an inconsistent state (if the gc method was used). The bottom line is: there is necessarily NO safe way to clean up a rogue thread, and if a thread does go rogue, the whole process should be condemned. If the source of the problem is a blocking operation, the solution is simple: don't use blocking operations! Otherwise, if your client thread is "cooperative" then checking a cancellation flag at judicious points is tedious, but the best solution. What you REALLY want here is a Monadic combinator to automate the checking .. :) > P.S. If your computations need to interact with the ui, forking is > out of question. It isn't out of the question, but is very nasty ;( -- John Skaller Felix, successor to C++: http://felix.sf.net