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

[Nicolas Pouillard]

On Wed, Nov 9, 2011 at 1:50 PM, Duncan Coutts
<duncan.coutts at googlemail.com> wrote:
> 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.

I support Duncan's view. Have a way to opt-out for experts.

-- 
Nicolas Pouillard
http://nicolaspouillard.fr