
On Thu, Dec 29, 2011 at 11:49 AM, Donn Cave
Quoth Antoine Latter
, ... 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