Version française
Home     About     Download     Resources     Contact us    
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: -- (:)
From: Alessandro Baretta <a.baretta@b...>
Subject: Re: [Caml-list] The best way to circumvent the lack of Thread.kill ?
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