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

[Duncan Coutts]

On 9 November 2011 12:13, Duncan Coutts <duncan.coutts at googlemail.com> wrote:
> On 9 November 2011 03:02, Ian Lynagh <igloo at earth.li> wrote:

>> I've just reread the thread, and I think the best way forwards would be
>> to make the original proposed change now, and for the above change to be
>> proposed separately.
>>
>> By making the proposed change now, we eliminate the unexpected locking
>> behaviour, and the API effectively doesn't change (I say "effectively",
>> because the semantics are obviously different, but I doubt anyone is
>> relying on getting an exception due to the Haskell locking).

> So far, I've not hear a single justification for turning off locking
> by default. Well, Ian says it's "unexpected", but has not addressed
> the purpose of the locking to prevent "unexpected"ly concurrently
> modifying a file that you're reading, i.e. said if he thinks this is
> worthless or not. The only justifications I've seen have been for
> changing the Windows locking approach to match unix, and the need for
> people to opt-out of locking.

Henning raises a good point:

writeFile path . process =<< readFile path

This is an excellent motivating example for why the Haskell committee
included locking in the first place.

This example will currently give a runtime error (which no doubt could
be improved). If we remove the default locking then this example
changes from a situation where a new user gets an unexpected locking
error into one where the new user gets unexpected file corruption. The
latter is *much* worse.

Concurrently modifying a file that you are reading can happen in any
language, so why is it that Haskell has locking by default and e.g.
Python does not (except perhaps historical accident that Python copied
C which has no protection for newbies). Well, it's simply more likely
to happen in Haskell, epsecially for new users who do not understand
the implications of lazy IO. Since we are not proposing to remove lazy
IO then we should also not remove the default locking.

Experts don't make these kinds of mistakes, so only bump into the
cases where they are intentionally modifying a file they're reading
and so are annoied by the default locking. That's fine, the experts
understand what is going on and can opt out.

Note also that readFile, writeFile etc are not a low level API where
we should avoid adding extra "cleverness". The Handle API is high
level, feature rich, convenient and used by newbies.

Note also that the file locking in the Haskell report has nothing to
do with some OS's doing locking by default. The H98/2010 report says:

  Implementations should enforce as far as possible, at least locally
to the Haskell process, multiple-reader single-writer locking on
files.

http://www.haskell.org/onlinereport/haskell2010/haskellch41.html#x49-32400041.3

All in all, the original reasons for including the default file
locking still hold. All we need is a way for experts to opt-out.

Further, I claim that the proposal should not be adopted as is,
because there is no consensus on the specific point of the default
locking. There is no consensus because that specific point has not
been addressed by more than two people. I suggest we extend the
discussion period and address the specific issue.

Duncan