f_offset

[Jeff Roberson]

On Sun, 13 Apr 2008, David Schultz wrote:

> On Sat, Apr 12, 2008, Jeff Roberson wrote:
>> It's worth discussing what posix actually guarantees for f_offset as well
>> as what other operating systems do.  POSIX actually does not guarantee any
>> behavior with simultaneous access.  Multiple readers may read the same
>> position in the file concurrently and update the position to different
>> offsets.  Multiple writers may write to the same file location, although
>> the io should be serialized by some other means.  Posix allows for and
>> Solaris, Linux, and historic implementations of f_offset work in the
>> following way:
>
> This is not entirely true. In particular, files opened with
> O_APPEND have stronger guarantees, and this behavior can be
> useful. For example, I imagine that a database that opens its log
> file with O_APPEND can depend on being able to write log entries
> concurrently without losing any data. (There are also stronger
> requirements for pipes, FIFOs, etc.)

As alfred mentioned append is handled in a different way.  I'm not 
suggesting we break posix semantics for append.  Also, pipes and fifos 
don't have an f_offset and you can't call seek on them.

>
> As I recall, empiricial evidence shows that SunOS 5.10 and FreeBSD
> both make stronger guarantees than Linux in the presence of
> multiple concurrent writers. I haven't tested readers or looked
> at the fdesc code for any of these.
>

Yes I slightly misspoke about solaris.  They use the exclusive vnode lock 
to protect f_offset for writers.  However, f_offset is fetched and set 
with a shared vnode lock for readers.  These are the same semantics that 
I'm proposing.

Thanks,
Jeff