[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Tim Murphy
Subject: Re: [bug #33138] .PARLLELSYNC enhancement with patch
Date: Wed, 24 Apr 2013 22:55:59 +0100

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

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

You could help some brave and decent people to have access to uncensored news by making a donation at:


reply via email to

[Prev in Thread] Current Thread [Next in Thread]