[Haskell-cafe] Spurious program crashes

[Bulat Ziganshin]

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 at HotPOP.com