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 -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
