
[Arg. Just lost the mail and have to re-type it. Sorry if I’m not as verbose as I should be]. Hi, I’m writing a TCP server app ATM. It has one thread per client. Some of the clients want to be notified if the internal state changes, while others are happily chatting with the server, possible modifying the internal state. What I need now is a way for the chatting thread to signal “anyone interested” that the state has changed. The semantics should be roughly these: * All listening threads run some wait-for-signal command that blocks until the signal is sent. * The state changing thread notifies the others by some signal-sending-command, which should not block. * It does not matter if no one is listening, or if threads miss signals because they are doing something else for the moment, or if several sent signals are handled only once. Here is my implementation so far: newtype MSignal a = MS (MVar a) newMSignal = MS `liftM` newEmptyMVar sendMSignal (MS mv) v = do forkIO $ takeMVar mv >> return () -- Cleanup afterwards putMVar mv v receiveMSignal (MS mv) = readMVar mv It builds on MVar’s promise that takeMVar and readMVar commands are handled FIFO, so by spawning a takeMVar thread, the sender ensures that exactly after all currently waiting threads are served the value is taken out of the MVar and everything is done. readMVar will both take the value and put it back, so that the next waiting thread (or the sending thread’s cleanup thread) can take the value. Do you think this is a sensible way to do it? Any pitfalls that I have overlooked? Might this be useful enough to be included in some mainstream library? Greetings, Joachim -- Joachim Breitner e-Mail: mail@joachim-breitner.de Homepage: http://www.joachim-breitner.de ICQ#: 74513189

On Fri, May 25, 2007 at 07:57:45PM +0200, Joachim Breitner wrote:
I???m writing a TCP server app ATM. It has one thread per client. Some of the clients want to be notified if the internal state changes, while others are happily chatting with the server, possible modifying the internal state. What I need now is a way for the chatting thread to signal ???anyone interested??? that the state has changed.
Did you consider using STM for thread synchronisation and communication? STM uses change notifications (or something similar) internally to implement the "retry" operation. I might be just what you need, but more high level. Best regards Tomek

Hi, Am Samstag, den 26.05.2007, 14:29 +0200 schrieb Tomasz Zielonka:
On Fri, May 25, 2007 at 07:57:45PM +0200, Joachim Breitner wrote:
I???m writing a TCP server app ATM. It has one thread per client. Some of the clients want to be notified if the internal state changes, while others are happily chatting with the server, possible modifying the internal state. What I need now is a way for the chatting thread to signal ???anyone interested??? that the state has changed.
Did you consider using STM for thread synchronisation and communication? STM uses change notifications (or something similar) internally to implement the "retry" operation. I might be just what you need, but more high level.
No, I haven’t done anything with STM yet. Maybe I’ll look into that. Thanks, Joachim -- Joachim Breitner e-Mail: mail@joachim-breitner.de Homepage: http://www.joachim-breitner.de ICQ#: 74513189

On Sun, May 27, 2007 at 12:22:54PM +0200, Joachim Breitner wrote:
Hi,
Am Samstag, den 26.05.2007, 14:29 +0200 schrieb Tomasz Zielonka:
On Fri, May 25, 2007 at 07:57:45PM +0200, Joachim Breitner wrote:
I???m writing a TCP server app ATM. It has one thread per client. Some of the clients want to be notified if the internal state changes, while others are happily chatting with the server, possible modifying the internal state. What I need now is a way for the chatting thread to signal ???anyone interested??? that the state has changed.
Did you consider using STM for thread synchronisation and communication? STM uses change notifications (or something similar) internally to implement the "retry" operation. I might be just what you need, but more high level.
Of course it is not "I" that you might need, but "It" - the STM :-) Writing "I" instead of "It" is one of the most frequent errors I make when writing in english - perhaps a sign of egocentrism...?
No, I haven???t done anything with STM yet. Maybe I???ll look into that.
If your threads just wait until the server state satisfies some condition, then STM should fit naturally. Best regards Tomek

Hello Joachim, Friday, May 25, 2007, 9:57:45 PM, you wrote:
I’m writing a TCP server app ATM. It has one thread per client. Some of the clients want to be notified if the internal state changes, while others are happily chatting with the server, possible modifying the internal state. What I need now is a way for the chatting thread to signal “anyone interested” that the state has changed.
i don't read your letter carefully but at least there is throwTo function what implement exactly what you said in subj. look Control.Exception module docs and read "awkward squad" paper: "Tackling the awkward squad: monadic input/output, concurrency, exceptions, and foreign-language calls in Haskell" http://research.microsoft.com/Users/simonpj/papers/marktoberdorf/marktoberdo... -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

Hi, Am Sonntag, den 27.05.2007, 14:07 +0400 schrieb Bulat Ziganshin:
Hello Joachim,
Friday, May 25, 2007, 9:57:45 PM, you wrote:
I’m writing a TCP server app ATM. It has one thread per client. Some of the clients want to be notified if the internal state changes, while others are happily chatting with the server, possible modifying the internal state. What I need now is a way for the chatting thread to signal “anyone interested” that the state has changed.
i don't read your letter carefully but at least there is throwTo function what implement exactly what you said in subj. look Control.Exception module docs and read "awkward squad" paper:
"Tackling the awkward squad: monadic input/output, concurrency, exceptions, and foreign-language calls in Haskell" http://research.microsoft.com/Users/simonpj/papers/marktoberdorf/marktoberdo...
I don’t like throwTo because then I need to keep track of which threads are currently interested in the signal, to not accidentally throw an exception to a thread that does not expect it. Just seems too dangerous to me :-) Greetings, Joachim -- Joachim Breitner e-Mail: mail@joachim-breitner.de Homepage: http://www.joachim-breitner.de ICQ#: 74513189
participants (3)
-
Bulat Ziganshin
-
Joachim Breitner
-
Tomasz Zielonka