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 6ABD1D45F for ; Wed, 2 Nov 2005 19:29:07 +0100 (CET) Received: from karpinski.uscs.susx.ac.uk (karpinski.uscs.susx.ac.uk [139.184.14.85]) by nez-perce.inria.fr (8.13.0/8.13.0) with ESMTP id jA2IT6dG012823 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 2 Nov 2005 19:29:07 +0100 Received: from cpc1-brig7-3-0-cust179.brig.cable.ntl.com ([82.4.141.179]:52895) by karpinski.uscs.susx.ac.uk with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.43) id IPCBDJ-000EGO-6X for caml-list@yquem.inria.fr; Wed, 02 Nov 2005 18:29:43 +0000 Subject: Re: [Caml-list] The best way to circumvent the lack of Thread.kill ? From: David Teller To: OCaml In-Reply-To: <436908B9.8080001@barettadeit.com> 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> Content-Type: text/plain; charset=UTF-8 Date: Wed, 02 Nov 2005 18:29:03 +0000 Message-Id: <1130956143.6564.17.camel@titania> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 Content-Transfer-Encoding: quoted-printable X-Miltered: at nez-perce with ID 43690572.002 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; caml-list:01 ens-lyon:01 rephrase:01 threads:01 indirection:01 cheers:01 baretta:01 mistaken:01 hypothetical:01 threads:01 ...:98 wrote:01 exception:01 exception:01 functions: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.6 required=5.0 tests=NO_OBLIGATION autolearn=disabled version=3.0.3 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 =3D 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 =3D 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);=20 (*Actually, this operation throws=20 Event.Closed_channel*) f Event.sync (Event.receive c) in let c =3D 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.=20 Cheers, David Le mercredi 02 novembre 2005 =C3=A0 19:43 +0100, Alessandro Baretta a =C3= =A9crit : > David Teller wrote: >=20 > > 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 no= t > > a core feature of channels. After all, unless I'm mistaken, channels ar= e > > 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). > >=20 > > Or did I miss something ? >=20 > "Channel" is maybe an inappropriate term for this strange object. An=20 > Event.channel is more like a single-slot mailbox to pass a message to=20 > someone. Any number of Threads (zero upwards) can be waiting for=20 > messages on a channel. There is no obligation that there be exactly one=20 > thread to kill on the other side. What would happen is try to send a=20 > hard-kill event on a channel where there is nobody on the other side?=20 > What if the there is more than one thread? >=20 > You are trying to find a way around killing a thread with Thread.kill,=20 > but there is really no way to cleanly kill a thread asynchronously. A=20 > clean exit requires some cooperation from the killed thread. >=20 > Alex --=20 Read, Write, and Publish Standard eBooks Free, Open Software, Open Standards and multi-platform The OpenBerg project http://www.openberg.org