Version française
Home     About     Download     Resources     Contact us    

This site is updated infrequently. For up-to-date information, please visit the new OCaml website at

Browse thread
The best way to circumvent the lack of Thread.kill ?
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2005-11-02 (18:29)
From: David Teller <David.Teller@e...>
Subject: Re: [Caml-list] The best way to circumvent the lack of Thread.kill ?
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 
   f Event.sync (Event.receive c)

   let c = Event.new_channel ()
     ignore (Thread.create sender c);
       receiver print_int c
       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. 


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 
> 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