From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by yquem.inria.fr (Postfix) with ESMTP id 54E40D45F for ; Wed, 2 Nov 2005 18:00:21 +0100 (CET) Received: from lynndie.uscs.susx.ac.uk (lynndie.uscs.susx.ac.uk [139.184.14.87]) by nez-perce.inria.fr (8.13.0/8.13.0) with ESMTP id jA2H0K93003101 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 2 Nov 2005 18:00:21 +0100 Received: from calaf.rn.informatics.scitech.susx.ac.uk ([139.184.48.199]:50547) by lynndie.uscs.susx.ac.uk with esmtp (Exim 4.43) id IPC78K-000DKD-GR for caml-list@yquem.inria.fr; Wed, 02 Nov 2005 17:00:20 +0000 Subject: Re: [Caml-list] The best way to circumvent the lack of Thread.kill ? From: David Teller Reply-To: David.Teller@ens-lyon.org To: OCaml In-Reply-To: <4368E835.7090501@barettadeit.com> References: <43688C4C.2080606@inria.fr> <1130943226.4565.11.camel@calaf.rn.informatics.scitech.susx.ac.uk> <4368E835.7090501@barettadeit.com> Content-Type: text/plain Date: Wed, 02 Nov 2005 17:00:08 +0000 Message-Id: <1130950809.4565.42.camel@calaf.rn.informatics.scitech.susx.ac.uk> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-22) Content-Transfer-Encoding: 7bit X-Miltered: at nez-perce with ID 4368F0A4.002 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; caml-list:01 ens-lyon:01 exn:01 bool:01 mistaken:01 hypothetical:01 cheers:01 baretta:01 threads:01 computations:01 exn:01 wrote:01 wrote:01 exception:01 exception:01 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.0.3 Thanks for the answer. A (unit Event.channel) or a (exn Event.channel), combined with (Event.poll), or perhaps a simple (bool Event.channel), would indeed permit soft-killing a thread during a synchronization phase meant explicitly for that purpose. A thunk computation could even generalize this to actual communications, at the price of a somewhat strange type. However, in my mind, all these solutions are the channel equivalent of manual error-handling -- something akin to a function returning an ('a option) instead of an 'a because the result None is reserved for errors. I'm still slightly puzzled as to why this distant killing/raising is not a core feature of channels. After all, unless I'm mistaken, channels are a manner of implementing continuations. I tend to believe I should be able to raise an error (a hypothetical Event.raise/Event.kill) instead of returning/passing a value (as in Event.send). Or did I miss something ? Cheers, David On Wed, 2005-11-02 at 17:24 +0100, Alessandro Baretta wrote: > David Teller wrote: > > I would have figured that the best way to properly kill a thread would > > be to have some form of channel (i.e. Events.t)-based communication > > between threads -- and then killing the channel. > > > > Trouble is that, as I've just realized, there is no such facility as > > killing/sending an exception through a channel. Does anyone know why ? > > Event.channel is a type constructor which takes an argument identifying > the type of objects that are sent over the channel. You can send thunk > computations ((unit -> 'a) Event.channel), which may very well raise an > exception. Or you can simply send an exception (exn Event.channel). > Finally, you can send "()" on a channel (unit Event.channel), whose sole > purpose is to communicate soft-kill requests. > > Alex -- Read, write and publish e-books, Free software, Open standards, Open source, The OpenBerg project -- http://www.openberg.org