why not use a named semaphore wherever possible (windows and linux) and lock a file where not instead of trying to pass kernel object handles around (seems a bit nasty to me)?
On 24 April 2013 21:19, Paul Smith <psm...@gnu.org> wrote: > On Wed, 2013-04-24 at 22:39 +0300, Eli Zaretskii wrote: > > > Nothing is actually read by lseek (and even if it were, it would > > > only need to look at the first and last part of the file, not read > > > all the content, if that was the worry). > > > > Are you sure? How can lseek "jump" to the last byte of the file, if > > the file is not contiguous on disk, except by reading some of it? > > If fstat() can get the size from an internal structure then lseek() can > do the same, then just update the file descriptor's position. I don't > think there's more to it than setting that value, but it could be. > Certainly at the filesystem layer we don't know, and we don't care, > about things like whether the file is kept contiguously at the block > layer. > > As you say, we should just measure. > > > Or maybe we should abandon this optimization and take the lock > > regardless. How bad can that be? > > Well, we want to know if the file has any content anyway: for example we > don't want to output the enter/leave notifications if there's nothing to > print. So there's no extra cost to avoiding the lock here. > > > > _______________________________________________ > Bug-make mailing list > Bug-make@gnu.org > https://lists.gnu.org/mailman/listinfo/bug-make > -- You could help some brave and decent people to have access to uncensored news by making a donation at: http://www.thezimbabwean.co.uk/friends/
_______________________________________________ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
