Proposal: Stop enforcing single-writer-multi-reader file access

[Duncan Coutts]

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