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