Re: file offset corruption on 32-bit machines?

[lsorense@csclub.uwaterloo.ca (Lennart Sorensen)]

On Tue, Apr 15, 2008 at 10:06:47PM +0200, Pavel Machek wrote:
> Of course I can write an application that will be broken by this, and
> was not broken before. It will be slightly nasty code. Come on, you
> can do this too ;-).

Well it would take seriously hard work to make a program that would work
correctly if it was atomic and would break if it isn't.  Certainly a
normal program that just tries to seek and read/write should never have
any issue.

> That would be very wrong addition to documentation. If you really
> wanted to do something like this, you would probably want to say
> something like
> 
> "Doing concurrent seeks on one file is undefined. Kernel may end up
> with seeking to some other place."

Well perhaps that is a lot simpler.

> Unfortunately, you'd have to get this addition into POSIX standard...

Well I do see something in a PDF on posix I found that says all posix
functions (at least in POXIS.1 which I think might be an old name for
it) are thread safe unless stated otherwise, so since lseek doesn't
state otherwise I suppose it better be completely thread safe in all
cases.  It seems a bit stupid given any program that wants to work
reliably has to do its own locking already, so why waste time on it in
the kernel.  Any way the kernel could know how many copies of the
filehandle exist (yeah right, of course not) to ensure that it only has
to lock if there is multiple accesses going on?  Darn.

Those stupid standards documents. :)

-- 
Len Sorensen