On 9 Nov 2009, at 17:41, Neil Brown wrote:
Just to clarify -- I meant access to another MVar. Basically, if I do this:
do v <- newMVar addObserver sub (putMVar v)
If when the observers are run, the MVar v (that I've allocated) is non-empty, my code will block until it is empty, which will also block all the subsequent observers from being run (and block the code that called setValue) until the MVar is cleared by another thread. So my one poorly-written observer could deadlock (or cause stutter in) the system, whereas in the forkIO version, this observer would be fine -- it would block in its own new thread.
Ah yes, of course - I understand. Of course, there's nothing really to stop application authors doing such things in the main thread too... ;-) Thanks for the clarification, -Andy