On Wed, 2011-10-26 at 23:59 +0100, Ian Lynagh wrote:
Hi all,
Haskell currently requires that multiple-reader single-writer locking is used on files. I understand the motivation for this was to try to protect people from running into problems due to lazy IO, but in practice I think it just causes more problems than it solves.
The decision may also have been influenced by the belief that this behaviour is enforced for all programs on Windows, but I am told that it is possible to get lock-free behaviour on Windows too.
I propose that we remove all the automatic locking from the libraries, and let the user do any locking that they wish to do themselves.
Attached are patches for ghc, base, process and unix. (not yet tested on Windows).
I have to say, I'm a little reticent about this. Certainly it's useful to be able deliberately to have multiple writers, or to be able deliberately to read a file while also writing to it. But doing so accidentally seems like a bug waiting to happen doesn't it? Do we really want to make this the default everywhere? What about keeping the check by default but adding something to turn off the locking when that's intentional. That'd mean a param of openFile (which incidentally is ripe for converting to take a record of these various parameters, like we have for createProcess). For Windows, it'd be fine to switch from using OS-level file locking to intra-process RTS-level locking as we use on Unix. That is, only protecting ourselves from bugs in our own code where we read and write, not protecting from other processes. And if you switch the default and users have to do their own locking, how can they do it? I'm not sure there is any sensible way to do it. Any bit of IO code can open any file. If they're already tightly coupled and can share an MVar it's fine, but that's not the sort of accidental situation that the current implicit locking protects against. Duncan