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

[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).

We can separately, perhaps even initially in a separate library, think
about what the best replacement design is. For example, we may wish to
pass openFile a lock and unlock function, rather than just having a Bool
to control whether it uses its own internal locking. Either way, I think
we ought to have access to base's locking functions, so that we can use
them with FFI imports that do file IO.


As Duncan said, if any supporters of the original proposal disagree with
this approach, please speak up!


Thanks
Ian