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