There are several cases in which multiple threads racing putMVar is> ...
correct. Consider e.g. a server thread encapsulating state, which needs to rate limit its clients. The server is put behind a MVar
to which all the clients putMVar and thus block until the server is ready
The server thread uses tryTakeMVar for its job.
Now add a debug function:
debug :: MVar SCoreT -> IO () debug mv = tryReadMVar mv >>= maybe (putStrLn "Nothing") print
And suddenly we have a created a subtle bug in the code with flawed tryReadMVar implementation.
Indeed, but depending upon the vagaries of scheduling, you may in fact be guaranteed *never* to see any output (eg, when tryTakeMVar yields on empty and putMVar yields unconditionally).
I was, however, curious what use you had in mind where writes were racing, but where you nonetheless wanted to perform blind non-blocking reads. Such situations are generally fraught with peril. In this case, the peril is starvation of the debug thread---which you may or may not actually care about.
-Jan-Willem Maessen
_______________________________________________ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
