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

[Jonathan Bryant <jtbryant@valdosta.edu>]

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