Re: CVS commit: src/bin/cp

[David Laight <david%l8s.co.uk@localhost>]

On Sun, Oct 24, 2010 at 05:21:06AM +0000, David Holland wrote:
> 
> Because individual write() calls are supposed to be atomic, I don't
> think there is such a thing as a locking improvement that'll help with
> this behavior. :-/

I think write() only needs to lock the the file enough to ensure that
the file offset is correct. Possibly the written range needs locking
against other accesses - but I think the app is supposed to use file
locking for that (and mmap will always be non-atomic w.r.t. write).

Actually if 2 writes are issued for the same part of a file, the
kernel can act as if they were requested in either order - since the
app(s) cannot know the order the calls would be made in!
Which means it could just sleep the 2nd write until the first terminates!

Writes with O_APPEND (and writes that extend the file) are more
problematical since you cant allow a second such write to start until
the first has completed - for instance it might try to read from
an unmapped user-space address and return a short length.

> Except I guess going to some kind of multiversion model for vnodes.

Don't you just need 2 locks? One for locking the data areas, and the
other for the file data itself.

        David

-- 
David Laight: david%l8s.co.uk@localhost