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 concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by yquem.inria.fr (Postfix) with ESMTP id 2A2ECD45F for ; Wed, 2 Nov 2005 18:41:14 +0100 (CET) Received: from mail.barettadeit.com (h213-255-109-130.albacom.net [213.255.109.130] (may be forged)) by concorde.inria.fr (8.13.0/8.13.0) with ESMTP id jA2HfDdX015282 for ; Wed, 2 Nov 2005 18:41:13 +0100 Received: from [10.0.0.10] (host73-158.pool8263.interbusiness.it [82.63.158.73]) by mail.barettadeit.com (Postfix) with ESMTP id 9C17B84141; Wed, 2 Nov 2005 18:45:39 +0100 (CET) Message-ID: <436908B9.8080001@barettadeit.com> Date: Wed, 02 Nov 2005 19:43:05 +0100 From: Alessandro Baretta User-Agent: Debian Thunderbird 1.0.2 (X11/20050602) X-Accept-Language: en-us, en MIME-Version: 1.0 To: David.Teller@ens-lyon.org Cc: OCaml Subject: Re: [Caml-list] The best way to circumvent the lack of Thread.kill ? References: <43688C4C.2080606@inria.fr> <1130943226.4565.11.camel@calaf.rn.informatics.scitech.susx.ac.uk> <4368E835.7090501@barettadeit.com> <1130950809.4565.42.camel@calaf.rn.informatics.scitech.susx.ac.uk> In-Reply-To: <1130950809.4565.42.camel@calaf.rn.informatics.scitech.susx.ac.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Miltered: at concorde with ID 4368FA39.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; baretta:01 baretta:01 caml-list:01 mistaken:01 hypothetical:01 threads:01 wrote:01 cleanly:01 passing:01 thread:02 thread:02 tend:02 slightly:02 puzzled:02 alessandro:03 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.6 required=5.0 tests=FORGED_RCVD_HELO, NO_OBLIGATION autolearn=disabled version=3.0.3 David Teller wrote: > 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 ? "Channel" is maybe an inappropriate term for this strange object. An Event.channel is more like a single-slot mailbox to pass a message to someone. Any number of Threads (zero upwards) can be waiting for messages on a channel. There is no obligation that there be exactly one thread to kill on the other side. What would happen is try to send a hard-kill event on a channel where there is nobody on the other side? What if the there is more than one thread? You are trying to find a way around killing a thread with Thread.kill, but there is really no way to cleanly kill a thread asynchronously. A clean exit requires some cooperation from the killed thread. Alex