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

[Duncan Coutts]

On 9 November 2011 03:02, Ian Lynagh <igloo at earth.li> wrote:
> On Tue, Nov 08, 2011 at 01:07:23PM +0000, Duncan Coutts wrote:
>>
>> We should take the same approach with openFile. Currently we have:
>>
>> openFile :: FilePath -> IOMode -> IO Handle
>>
>> I suggest changing the IOMode for a record of options which would
>> include the IO mode (read/write/read-write/etc), and other things like
>> file locking, default create permissions, create exclusive etc. Again,
>> we'd use a default value and override extra options as necessary.
>
> 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).

But you're still proposing removing all protections when the initial
complaint was simply to change the behaviour on Windows to match the
behaviour on Unix. That complaint is about Haskell processes locking
files such that other processes cannot read them (which we all agree
is annoying).

A slightly different (and also legitimate) complaint is the current
inability to opt-out of locking.

So I think the best way forward is to scap the windows OS-level
locking implementation and to use the RTS-based one on all platforms.

Then separately we can talk about redesigning openFile to give people
control over the locking (mostly the ability to opt-out).

Of course you'll not hear complaints from people relying on getting a
locking exception, that's the whole point about it being there to
catch accidental cases. The only complaints you'll hear will be from
the people who need to opt-out of locking (there are few such cases
but they're important where they do occur).

Are you suggesting we turn off all locking by default, and then turn
it back on again by default once we change openFile? That kind of
switching back and forth doesn't seem like a good idea. If you're
saying now, lets turn it off and keep it off, then there's almost no
point in changing openFile. Nobody is going to use openFile locking
for the prevention of accidents. It has to be a default for that. And
that was presumably the original rationale for H98.

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.

Note also that in future we could make the "unexpected" aspect better
if the locking error message points people in the right direction to
turn off locking (via the future openFile change), if they decide
that's what they decide is the right solution.

Duncan