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 4DA6BBB9A for ; Wed, 9 Nov 2005 02:18:38 +0100 (CET) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.204]) by concorde.inria.fr (8.13.0/8.13.0) with ESMTP id jA91Ibqf022279 for ; Wed, 9 Nov 2005 02:18:37 +0100 Received: by zproxy.gmail.com with SMTP id x3so45718nzd for ; Tue, 08 Nov 2005 17:18:36 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=efQzERNjCMpQWIbbVIvJV9sioUTnj2OgYCiHyrZXZe7stDm1e+0IUBac3HXIlxNnFQiuJb/bWQ8U7Hp49YWBvermqyu6Pstz4JJl75Pe3A3KIt7ZHlvKN7ohD7I9nsbNud94JIHl2jQDqzLnyaXdDgw+BEeR8iVL+isBjcD/Xss= Received: by 10.65.139.13 with SMTP id r13mr162657qbn; Tue, 08 Nov 2005 17:18:36 -0800 (PST) Received: by 10.65.52.1 with HTTP; Tue, 8 Nov 2005 17:18:36 -0800 (PST) Message-ID: Date: Wed, 9 Nov 2005 10:18:36 +0900 From: =?ISO-8859-1?Q?Gr=E9gory_Guyomarc=27h?= To: jtbryant@valdosta.edu Subject: Re: [Caml-list] The best way to circumvent the lack of Thread.kill ? Cc: caml-list@yquem.inria.fr In-Reply-To: <1131482174.6590.23.camel@starlight> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_3475_10664963.1131499116767" 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> <1131482174.6590.23.camel@starlight> X-Miltered: at concorde with ID 43714E6D.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; guyomarc'h:01 caml-list:01 higher-order:01 uchicago:01 reppy:01 higher-order:01 uchicago:01 reppy:01 ocaml:01 threads:01 threads:01 rephrase:01 indirection:01 cheers:01 baretta: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=HTML_30_40,HTML_MESSAGE, NO_OBLIGATION,RCVD_BY_IP autolearn=disabled version=3.0.3 ------=_Part_3475_10664963.1131499116767 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hello, I found these two references useful to understand the Event library: *CML: A higher-order concurrent language* John H. Reppy, In *ACM SGPLAN '91 Conference on Programming Language Design and Implementation*, pages 293-305. ACM Press, 1991. http://portal.acm.org/ft_gateway.cfm?id=3D113470&type=3Dpdf *Higher-order Concurrency* John H. Reppy, *Computer Science Technical Report 92-1285*, Cornell University, June 1992. http://people.cs.uchicago.edu/~jhr/papers/1992/phd-thesis.html I think there is also a short example on how to use this module in OCaml Oreilly book. Hope this helps, Gregory. On 11/9/05, Jonathan Bryant wrote: > > 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 a= n > > exception to whoever is actually synchronising on a channel. Perhaps an= y > > 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); > > (*Actually, this operation throws > > 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. > > > > Cheers, > > David > > > > Le mercredi 02 novembre 2005 =E0 19:43 +0100, Alessandro Baretta a =E9c= rit : > > > 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 i= s > not > > > > a core feature of channels. After all, unless I'm mistaken, channel= s > 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 > > > > _______________________________________________ > Caml-list mailing list. Subscription management: > http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list > Archives: http://caml.inria.fr > Beginner's list: http://groups.yahoo.com/group/ocaml_beginners > Bug reports: http://caml.inria.fr/bin/caml-bugs > ------=_Part_3475_10664963.1131499116767 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hello,

I found these two references useful to understand the Event library:

= CML: A higher-order concurrent= language
John H. Reppy, In ACM SGPLAN '91 Conference on Programming Language Design and Implementation, pages 293-305. ACM Press, 1991. http://portal.acm.org/ft_gateway.cfm?id=3D113470&type=3Dpdf

Higher-order Concurrency
John H. Reppy, Computer Science Technical Report 92-1285, Cornell University, June 1992.
= http://people.cs.uchicago.edu/~jhr/papers/1992/phd-thesis.html

I think there is also a short example on how to use this module in OCaml Or= eilly book.

Hope this helps,
Gregory.

On 11/9/05, Jonathan Bryant <jtbrya= nt@valdosta.edu> wrote:
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 mi= ssing 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'sgoing on.

Second, the Thread module allows for individual thread si= gnal masks, but
no way to signal specific, individual threads. &nbs= p;It just has a way to
signal one of them pseudo-randomly.  Since the signal masks o= nly work
under Unix, why isn't Thread.kill mapped to pthread_kill() sinc= e that
would allow much greater flexibility by allowing individual speci= fic
threads to be signaled?

--Jonathan

On Wed, 2005-11-02 at 13:2= 9, David Teller wrote:
> Let me rephrase. I don't want to kill just a= ny thread, I want to send an
> exception to whoever is actually synch= ronising on a channel. Perhaps any
> exception can be "distantly thrown", or perhaps only one= specific kind.
> Something like
>
>  let sende= r c =3D
>    ignore Event.sync (Event.send c 1);<= br>>       (**Event.send passes an informa= tion,
>          while E= vent.sync may pass control.*)
>    ignore Event.s= ync (Event.send c 2);
>    ignore Event.sync (Eve= nt.send c 4);
>    ignore Event.sync (Event.kill = c)
>
>  and receiver f c =3D
>    f Event.sync (Event.receive c);
>&nbs= p;       (**Event.receive receive an inf= ormation,
>         &nbs= p; while Event.sync may pass control.*)
>    f Ev= ent.sync (Event.receive c);
>    f Event.sync (Event.receive c);
>    f Event.sync (Event.rece= ive c);
>       (*Actually, this operat= ion throws
>         &nb= sp; Event.Closed_channel*)
>    f Event.sync (Eve= nt.receive c)
>
>  in
>    = let c =3D=20 Event.new_channel ()
>    in
>  &= nbsp;   ignore (Thread.create sender c);
>  =     try
>      &nbs= p; receiver print_int c
>      wit= h
>        x -> (*...*)>
>  In the case of more than two threads waiting for c= ommunication on a
> single channel, I would say that they all should receive the excep= tion
> during their next Event.sync.
>
>  I agr= ee 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.
>
> Chee= rs,
>  David
>
> Le mercredi 02 novembre 2005 = =E0 19:43 +0100, Alessandro Baretta a =E9crit :
> > David Teller w= rote:
> >
> > >  However, in my mind, all these solutions are = the channel equivalent of
> > > manual error-handling -- someth= ing akin to a function returning an ('a
> > > option) instead o= f an 'a because the result None is reserved for errors.
> > > I'm still slightly puzzled as to why this distant killin= g/raising is not
> > > a core feature of channels. After all, u= nless 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 somethi= ng ?
> >
> > "Channel" is maybe an inappropriate term f= or this strange object. An
> > Event.channel is more like a single= -slot mailbox to pass a message to
> > someone. Any number of Thre= ads (zero upwards) can be waiting for
> > messages on a channel. There is no obligation that there be e= xactly 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?
> >
&g= t; > You are trying to find a way around killing a thread with Thread.ki= ll,
> > but there is really no way to cleanly kill a thread asynch= ronously. A
> > clean exit requires some cooperation from the killed thread.<= br>> >
> > Alex
--
--Jonathan Bryant
  jtbryant@valdosta.edu
 &= nbsp;Student Intern
  Unix System Operations
  VSU Information Techn= ology

"Das Leben ohne Music ist einfach ein Irrtum, eine Strapa= ze, ein" Exil."
("Life without music is simply an error, = a pain, an exile.")
--Frederich Nietzsche

"The three cardinal values of a progr= ammer are laziness, impatience, and
hubris."
--Perl Man Page
=


_______________________________________________
Caml-list ma= iling list. Subscription management:
ht= tp://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
Archives: http://caml.inria.fr
Beginner's list:= =20 http://groups.yah= oo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs

------=_Part_3475_10664963.1131499116767--