Hello Joel, Tuesday, November 22, 2005, 1:41:38 AM, you wrote: JR> logger h die = JR> do empty <- isEmptyChan parent JR> unless empty $ do x <- readChan parent JR> putStrLn x JR> hPutStrLn h x JR> alive <- isEmptyMVar die JR> when (alive || not empty) $ logger h die can you just send Die message through the same Chan? it will be best solution. you can even write: logger h die = pid <- forkIO (readMVar die >> putChan parent DIE) go killThread pid where go = do x <- readChan parent case x of DIE -> return () _ -> do putStrLn x hPutStrLn h x go or try something like this: while isEmptyMVar while not isEmptyChan x <- readChan ... JR> I see clearly how using Maybe with getChanContents will work out JR> perfectly. I don't understand why the above code is inefficient to JR> the point of printing just a few messages (out of hundreds) out on JR> Windows. I would like to understand it to avoid such mistakes in the JR> future. is writing to channel and filling MVar done in different threads? if so, second thread may just get much more attention. and may be your code itself drive to this, for example because you are querying channel state with the same frequency as state of MVar ps: btw, for such sort of tasks like 'go' above i created control structure repeat_whileM. with its help first code will become just: logger h die = withThread (readMVar die >> putChan parent DIE) $ do repeat_whileM (readChan parent) (/=DIE) (\x -> putStrLn x >> hPutStrLn h x) withThread code = bracket (forkIO code) killThread . const repeat_whileM inp cond out = do x <- inp if (cond x) then do out x repeat_whileM inp cond out else return x -- Best regards, Bulat mailto:bulatz@HotPOP.com