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 6B058BB9A for ; Tue, 8 Nov 2005 21:34:07 +0100 (CET) Received: from mailx.valdosta.edu (VO44360.valdosta.edu [168.18.130.251]) by nez-perce.inria.fr (8.13.0/8.13.0) with ESMTP id jA8KY68I013865 for ; Tue, 8 Nov 2005 21:34:06 +0100 Received: from blazemail.valdosta.edu (VO44216.valdosta.edu [168.18.130.208]) by mailx.valdosta.edu (8.13.4/8.13.4) with ESMTP id jA8KY4W2020009 for ; Tue, 8 Nov 2005 15:34:05 -0500 (EST) (envelope-from jtbryant@valdosta.edu) Received: from starlight.valdosta.edu (VO00985.valdosta.edu [168.18.148.146]) by blazemail.valdosta.edu (iPlanet Messaging Server 5.2 HotFix 2.04 (built Feb 8 2005)) with ESMTP id <0IPN00K86L4SP0@blazemail.valdosta.edu> for caml-list@yquem.inria.fr; Tue, 08 Nov 2005 15:34:04 -0500 (EST) Date: Tue, 08 Nov 2005 15:36:15 -0500 From: Jonathan Bryant Subject: Re: [Caml-list] The best way to circumvent the lack of Thread.kill ? In-reply-to: <1130956143.6564.17.camel@titania> To: caml-list@yquem.inria.fr Reply-To: jtbryant@valdosta.edu Message-id: <1131482174.6590.23.camel@starlight> MIME-version: 1.0 X-Mailer: Ximian Evolution 1.4.5 (1.4.5-17) Content-type: text/plain; charset= Content-transfer-encoding: 8BIT 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> <436908B9.8080001@barettadeit.com> <1130956143.6564.17.camel@titania> X-PMX-Version: 5.0.2.153301, Antispam-Engine: 2.0.3.2, Antispam-Data: 2005.11.8.23 X-Miltered: at nez-perce with ID 43710BBE.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; caml-list:01 threads:01 threads:01 rephrase:01 indirection:01 cheers:01 baretta:01 mistaken:01 hypothetical:01 intern:01 ...:98 ohne:98 einfach:98 ein:98 ein:98 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=NO_OBLIGATION autolearn=disabled version=3.0.3 Ok. Two questions. First of all, what is going on in the Event module? I can't exactly get it to work an I fear I'm missing some important concept. I can't find any documentation other than the interface. Does anybody know of any further documeeentation or have a good explanation of exactly what's going on. Second, the Thread module allows for individual thread signal masks, but no way to signal specific, individual threads. It just has a way to signal one of them pseudo-randomly. Since the signal masks only work under Unix, why isn't Thread.kill mapped to pthread_kill() since that would allow much greater flexibility by allowing individual specific threads to be signaled? --Jonathan On Wed, 2005-11-02 at 13:29, David Teller wrote: > Let me rephrase. I don't want to kill just any thread, I want to send an > exception to whoever is actually synchronising on a channel. Perhaps any > exception can be "distantly thrown", or perhaps only one specific kind. > Something like > > let sender c = > ignore Event.sync (Event.send c 1); > (**Event.send passes an information, > while Event.sync may pass control.*) > ignore Event.sync (Event.send c 2); > ignore Event.sync (Event.send c 4); > ignore Event.sync (Event.kill c) > > and receiver f c = > f Event.sync (Event.receive c); > (**Event.receive receive an information, > while Event.sync may pass control.*) > f Event.sync (Event.receive c); > f Event.sync (Event.receive c); > f Event.sync (Event.receive c); > (*Actually, this operation throws > Event.Closed_channel*) > f Event.sync (Event.receive c) > > in > let c = Event.new_channel () > in > ignore (Thread.create sender c); > try > receiver print_int c > with > x -> (*...*) > > In the case of more than two threads waiting for communication on a > single channel, I would say that they all should receive the exception > during their next Event.sync. > > I agree that this is quite close to your idea of sending thunk > functions, but the additional indirection strikes me as odd for > something which to me looks like a primitive. > > Cheers, > David > > Le mercredi 02 novembre 2005 à 19:43 +0100, Alessandro Baretta a écrit : > > 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 -- --Jonathan Bryant jtbryant@valdosta.edu Student Intern Unix System Operations VSU Information Technology "Das Leben ohne Music ist einfach ein Irrtum, eine Strapaze, ein" Exil." ("Life without music is simply an error, a pain, an exile.") --Frederich Nietzsche "The three cardinal values of a programmer are laziness, impatience, and hubris." --Perl Man Page