atom feed18 messages in org.haskell.haskell-cafeRe: [Haskell-cafe] IORef memory leak
FromSent OnAttachments
Jim SnowJun 18, 2009 7:45 pm 
Ross MellgrenJun 18, 2009 8:55 pm 
Tim DockerJun 18, 2009 9:04 pm 
Jim SnowJun 18, 2009 9:09 pm 
Luke PalmerJun 18, 2009 9:45 pm 
Ross MellgrenJun 18, 2009 10:00 pm 
Don StewartJun 19, 2009 8:59 am 
Daniel van den EijkelJun 19, 2009 9:07 am 
Don StewartJun 19, 2009 9:08 am 
Claus ReinkeJun 19, 2009 9:29 am 
Don StewartJun 19, 2009 9:47 am 
Daniel van den EijkelJun 19, 2009 9:47 am 
Daniel van den EijkelJun 19, 2009 9:51 am 
Jim SnowJun 19, 2009 11:13 am 
Gregory CollinsJun 19, 2009 1:04 pm 
Evan LaforgeOct 15, 2010 10:47 am 
Gregory CollinsOct 15, 2010 1:30 pm 
Thomas SchillingOct 15, 2010 4:15 pm 
Subject:Re: [Haskell-cafe] IORef memory leak
From:Claus Reinke (clau@talk21.com)
Date:Jun 19, 2009 9:29:14 am
List:org.haskell.haskell-cafe

It is not possible to write a modifyIORef that *doesn't* leak memory!

Why? Or can one read about it somewhere?

Possibly, Don meant that 'modifyIORef' is defined in a way that does not allow to enforce evaluation of the result of the modification function (a typical problem with fmap-style library functions):

modifyIORef ref f = readIORef ref >>= writeIORef ref . f

No matter whether 'f' is strict or not, the 'writeIORef r' doesn't evaluate its result, just stores the unevaluated application:

> r<-newIORef 0 > modifyIORef r (\x->trace "done" $ x+1) > modifyIORef r (\x->trace "done" $ x+1) > readIORef r done done 2

If it had been defined like this instead

mRef r ($) f = readIORef r >>= (writeIORef r $) . f

it would be possible to transform the strictness of 'writeIORef r' to match that of 'f':

> r<-newIORef 0 > mRef r ($) (\x->trace "done" $ x+1) > mRef r ($) (\x->trace "done" $ x+1) > readIORef r done done 2 > r<-newIORef 0 > mRef r ($!) (\x->trace "done" $ x+1) done > mRef r ($!) (\x->trace "done" $ x+1) done > readIORef r 2

Claus