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

[Duncan Coutts]

On 9 November 2011 15:09, Jon Fairbairn <jon.fairbairn at cl.cam.ac.uk> wrote:
> Duncan Coutts <duncan.coutts at googlemail.com> writes:
>> 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.
>
> Indeed. It’s a long time ago, but I dimly remember discussions
> on these lines. Certainly there was an issue with lazy IO
> (attempting to make it morally referentially transparent), but
> one of the arguments was that, ideally, things like readFile
> should behave as if they were atomic, perhaps by means of shadow
> pages. So in the ideal semantics, the above programme would do
> what it appears to do, but there were complaints about
> efficiency and difficulty of implementation, so we settled on
> the locking approach (with a nod towards the difficulty of
> implementation in Windows).

Aye, if the OS would let us take copy-on-write snapshots of files then
that would be an improvement on locking while giving the same
serialisability semantics. This is much like what databases did with
things like MVCC multi-version concurrency control to increase
concurrency by removing row or table-based locking and making copies
as needed.

Some new filesystems do support copy-on-write but the OS doen't yet
provide much of an interface for apps to take advantage of it.

Something that is almost as good is atomically writing files.
Unfortunately this only works on Unix where you can atomically rename
over existing files that are open by your own or other processes.

> * * *
>
> For the cases where it is a problem, we need new modes, don’t
> we?

Yes, or maybe locking modes orthogonal to the read/write mode.

Duncan