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