On Thu, Dec 29, 2011 at 11:49 AM, Donn Cave <d...@avvanta.com> wrote: > Quoth Antoine Latter <aslat...@gmail.com>, > ... >>> http://www.haskell.org/pipermail/libraries/2011-October/016978.html >>> >>> ... wherein Ian Lynagh proposed to remove this feature and let the >>> programmer enforce locking or not, as in other programming languages' >>> base I/O libraries. This met with enthusiastic universal support, >>> so whatever the Report may say, it looks to me like the GHC libraries >>> will eventually not do this. >>> >> >> Wouldn't this lead to 'getContents' and friends being much less safe >> than they already are? Or would we have to do something at the GHC >> runtime level of things to add locking? > > Interesting question. I tend to steer clear of that function, rather > than try to keep track of all the things that can go wrong with it! > but I would guess, the effect is the same on any I/O strategy that > executes the same way: e.g. if you were to read pieces of the file > iteratively you would be similarly exposed to the possibility of > concurrent modifications. > > That risk may be less obvious with getContents if you take the naive > view that it returns the contents of the file in the same way that normal > I/O operations return data, but then you will eventually be punished for > that naivety anyway! > > Are you aware of some possible special issue with getContents? >
Well, the issue would more be with 'hGetContents'. Would this program then loop: append fromFilePath toFilePath = do str <- readFile fromFile writeFile toFile str if 'from' and 'to' where the same file? Currently the locking prevents this. Antoine _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe