Browse thread
The best way to circumvent the lack of Thread.kill ?
[
Home
]
[ Index:
by date
|
by threads
]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
[ 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 Event.Closed_channel*) f Event.sync (Event.receive c) in let c = Event.new_channel () in ignore (Thread.create sender c); try receiver print_int c with 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. Cheers, David 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 > 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 -- Read, Write, and Publish Standard eBooks Free, Open Software, Open Standards and multi-platform The OpenBerg project http://www.openberg.org