Re: [Caml-list] The best way to circumvent the lack of Thread.kill ?

["Grégory Guyomarc'h" <gregory.guyomarch@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 5372 bytes --]

Hello,

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

*CML: A higher-order concurrent
language*<http://people.cs.uchicago.edu/%7Ejhr/papers/1991/pldi-cml.html>
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=113470&type=pdf

*Higher-order Concurrency*<http://people.cs.uchicago.edu/%7Ejhr/papers/1992/phd-thesis.html>
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 <jtbryant@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 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
>
>
>
> _______________________________________________
> 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
>

[-- Attachment #2: Type: text/html, Size: 7586 bytes --]