On 21 November 2005 16:43, Joel Reymont wrote:
I'm being quite careful with resources these days. The outstanding issues are
1) Crashes on Mac OSX that are not reproduced on Linux, Windows, etc.
2) Some kind of a problem with Chan. getChanContents retrieves things smoothly, readChan only does it for the first few lines. Simon? Anyone?
After subsequent dicsussion, do you still think something strange was going on here? The code does look strange: logger :: MVar () -> IO () logger die = do empty <- isEmptyChan parent unless empty $ do x <- readChan parent putStrLn x alive <- isEmptyMVar die when (alive || not empty) $ logger die so this basically loops until there are no messages in the channel, and then exits. Is that what you wanted, or did you want it to keep reading from the channel until told to die? STM is a better solution, as already suggested. Without STM, the best way to do this is to multiplex everything into a single channel (i.e. send the die message down the channel).
3) Different performance of the logger thread on Mac OSX and Windows.
I'm having thousands of threads write their trace messages to a Chan. The logger On Windows I only see the first few lines of output when using isEmptyChan/readChan to retrieve values in a loop. On Mac OSX I do see smooth output.
Context switch behaviour might be different between MacOS X and Windows. With the above code, it might be that the logger thread found an empty channel at sp,e point and exited. Does that make sense?
On Windows I run out of memory because all the output sent to the chan builds up and is never processed. I can process it by replacing isEmptyChan/readChan with getChanContents but then my logger thread hangs forever (right semantics) and hangs everything else that waits for the logger thread to check an MVar and exit.
yes, because the logger thread has exited. Cheers, SImon