Thanks for the answer.

 A (unit Event.channel) or a (exn Event.channel), combined with 
(Event.poll), or perhaps a simple (bool Event.channel), would indeed
permit soft-killing a thread during a synchronization phase meant
explicitly for that purpose. A thunk computation could even generalize
this to actual communications, at the price of a somewhat strange type.

 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 ?

Cheers,
 David



On Wed, 2005-11-02 at 17:24 +0100, Alessandro Baretta wrote:
> David Teller wrote:
> >  I would have figured that the best way to properly kill a thread would
> > be to have some form of channel (i.e. Events.t)-based communication
> > between threads -- and then killing the channel.
> > 
> >  Trouble is that, as I've just realized, there is no such facility as
> > killing/sending an exception through a channel. Does anyone know why ?
> 
> Event.channel is a type constructor which takes an argument identifying 
> the type of objects that are sent over the channel. You can send thunk 
> computations ((unit -> 'a) Event.channel), which may very well raise an 
> exception. Or you can simply send an exception (exn Event.channel). 
> Finally, you can send "()" on a channel (unit Event.channel), whose sole 
>   purpose is to communicate soft-kill requests.
> 
> Alex
-- 
Read, write and publish e-books,
 Free software, Open standards, Open source,
  The OpenBerg project -- http://www.openberg.org