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