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

[David Teller <David.Teller@ens-lyon.org>]

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
-- 
Read, Write, and Publish Standard eBooks
  Free, Open Software, Open Standards and multi-platform
    The OpenBerg project http://www.openberg.org