From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from weis@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id OAA02955 for caml-redist; Thu, 11 May 2000 14:49:50 +0200 (MET DST) Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id KAA21795 for ; Tue, 9 May 2000 10:52:59 +0200 (MET DST) Received: from pauillac.inria.fr (pauillac.inria.fr [128.93.11.35]) by concorde.inria.fr (8.8.7/8.8.7) with ESMTP id KAA21113; Tue, 9 May 2000 10:52:57 +0200 (MET DST) Received: (from xleroy@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id KAA29308; Tue, 9 May 2000 10:52:57 +0200 (MET DST) Message-ID: <20000509105257.05370@pauillac.inria.fr> Date: Tue, 9 May 2000 10:52:57 +0200 From: Xavier Leroy To: Markus Mottl , OCAML Subject: Re: how to kill native code threads? References: <200005060009.CAA17778@miss.wu-wien.ac.at> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89.1 In-Reply-To: <200005060009.CAA17778@miss.wu-wien.ac.at>; from Markus Mottl on Sat, May 06, 2000 at 02:09:12AM +0200 Sender: weis > The documentation of the "Thread.kill" function says that it only works for > bytecode-level threads. > But how can I terminate native threads from outside? Say, for example, I > want to run some state space search on several processors and create native > threads that search a specific part of the search space. In general, killing threads at any point in their execution is unsafe, because the thread can die while holding critical resources, e.g. mutexes, and this will prevent other threads from running correctly. Thread.kill in the bytecode thread library is actually an historical error. It wasn't implemented in the native thread library because the underlying system threads (POSIX or Win32) explicitly discourage asynchronous thread cancellation. Thread.kill should have been removed from bytecode threads as well. (Similar things happen in Java: the original Java implementation supported thread termination at any time, but Java 2 deprecates this and proposes another mechanism.) > In the moment one returns with the solution I don't want the others > continue running. One could stop them by sending them some kind of stop > event, but the threads would have to check for this event at regular times, > which is unelegant to program and costs time: if the thread checks too > often, it will lose performance on the search; if it does so too seldom, we > might have a considerable delay until it reacts to the termination event. > > Is there another (safe) way to do it? Polling is always safe, if a bit inelegant. That's the solution that POSIX threads, Modula-3 and (I think) Java 2 encourage, with a bit of systems support to avoid problems with blocking operations. In the case of POSIX, for instance, a thread can post a "cancellation request" for another thread. By default, the target thread honors the cancellation request only when it tests explicitly for pending cancellation, or when it performs a potentially blocking operation (such as I/O or waiting on a condition variable). The default effect of cancellation is to terminate the thread, but user-provided functions can be called at cancellation time to e.g. release mutexes. In ML, this maps nicely to raising an exception in the target thread, which can then be caught to release mutexes and so on. Cancellation never occurs while waiting for a mutex, so that the state of a mutex is always predictable, even inside cancellation cleanup code. Then, there is the option of allowing immediate cancellation in pieces of long-running code that don't hold any resources. A recent paper by Marlow, Peyton-Jones and Moran (http://research.microsoft.com/Users/simonpj/papers/asynch-exns.ps.gz) proposes a symmetric approach: cancellation is immediate by default, but can be deferred over critical pieces of code using scoped "block" and "unblock" combinators. The POSIX model (or Peyton-Jones' variant) is a strong candidate for inclusion in the Caml threads libraries. Unfortunately, Win32 system threads do not provide adequate support for this model, so I'm not sure this can be made to work under Win32. - Xavier Leroy