Re: [bug #33138] .PARLLELSYNC enhancement with patch

[Tim Murphy]

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 <address@hidden> 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
address@hidden
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/