Re: file offset corruption on 32-bit machines?

Hi!

So if you write multithreaded code and don't understand what locking
around shared resources is for, then your application might break.

I think I know what locking around shared resources is for, which is why
I'm surprised the kernel doesn't do it.

Is it normal for a kernel resource not to be thread-safe (i.e. you don't
get advertised/sensible results if two threads access it at the same
time)?

If two threads are changing one filehandle at the same time, then the
program is broken. I can't see how the kernel making updates to 64bit
filehandles "atomic" helps. You could still seek in one thread, then
seek in another and then start the write in the first and get a wrong
result. Changes to a shared filehandle of any kind requires locking to
work reliably, so additional slow downs and locking in the kernel won't
fix anything.

Well, app may be broken, or it may be trying to confuse you.

If you were stracing app, it seeked at 1GB and at 7GB, then did
read(), you'd be certainly very surprised if it did read secret data
at 3GB, right?

And ptrace monitors do exist.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Relevant Pages