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

On Wed, Nov 9, 2011 at 1:50 PM, Duncan Coutts wrote:

On 9 November 2011 12:13, Duncan Coutts wrote:

...

On 9 November 2011 03:02, Ian Lynagh 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-3240004...

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