[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