From: Jonathan Bryant <jtbryant@valdosta.edu>
To: caml-list@yquem.inria.fr
Subject: Re: [Caml-list] The best way to circumvent the lack of Thread.kill ?
Date: Tue, 08 Nov 2005 15:36:15 -0500 [thread overview]
Message-ID: <1131482174.6590.23.camel@starlight> (raw)
In-Reply-To: <1130956143.6564.17.camel@titania>
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
next prev parent reply other threads:[~2005-11-08 20:34 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-11-02 9:52 Julien Narboux
2005-11-02 10:54 ` [Caml-list] " Richard Jones
2005-11-02 11:22 ` Julien Narboux
2005-11-02 13:00 ` Jacques Garrigue
2005-11-02 12:57 ` Julien Narboux
2005-11-02 13:23 ` Gerd Stolpmann
2005-11-02 14:00 ` Gerd Stolpmann
2005-11-02 14:32 ` Julien Narboux
2005-11-02 15:07 ` Gerd Stolpmann
2005-11-02 14:53 ` David Teller
2005-11-02 16:24 ` Alessandro Baretta
2005-11-02 17:00 ` David Teller
2005-11-02 18:43 ` Alessandro Baretta
2005-11-02 18:29 ` David Teller
2005-11-08 20:36 ` Jonathan Bryant [this message]
2005-11-09 1:18 ` Grégory Guyomarc'h
2005-11-09 12:37 ` Richard Jones
[not found] ` <4371A0A6.4010306@laposte.net>
2005-11-09 13:32 ` Jonathan Bryant
2005-11-02 11:33 EL CHAAR Rabih SGAM/AI/SAM
2005-11-08 3:23 ` Igor Pechtchanski
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1131482174.6590.23.camel@starlight \
--to=jtbryant@valdosta.edu \
--cc=caml-list@yquem.inria.fr \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox