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

[Paul Smith]

On Wed, 2013-04-24 at 21:17 +0300, Eli Zaretskii wrote:
> There's one issue that perhaps needs discussing.  A mutex is
> identified by a handle, which on Windows is actually a pointer to an
> opaque object (maintained by the kernel).  As such, using just 'int'
> for sync_handle is not wide enough, certainly not in 64-bit builds.
> Is it OK to use intptr_t instead?  Doing this cleanly might require to
> have a macro (I called it FD_FROM_HANDLE) to extract a file descriptor
> that is passed to a Posix fcntl; on Windows that macro will be a
> no-op, and on Posix platforms it's a simple cast.
> 
> Is this OK?

I think the "lock" or "lock handle" or whatever can be encapsulated into
a typedef, which will be different between the different platforms.
That sounds like a good abstraction to me.

We can even generalize the way in which we communicate the handle to
sub-makes; for example by calling a function with the handle that
returns a char*: if that value is non-NULL it's added to the command
line (maybe as a third element to the current jobs-fd argument).  If
it's null, nothing is added.  Then the submake can parse it out and hand
it back to a function that returns a handle again
(serialize/deserialize).  I'm not sure if this is necessary; it depends
on the details of the Windows model.

> > +/* Test whether a file contains any data. */
> > +static int
> > +fd_not_empty (int fd)
> > +{
> > +  return fd >= 0 && lseek (fd, 0, SEEK_END) > 0;
> > +}
> 
> Isn't this unnecessarily expensive (with large output volumes)?  Why
> not use fstat?

This lseek() doesn't actually move the file reference: SEEK_END plus an
offset of 0 is a no-op so it doesn't matter how large the file is.  This
is just seeing if the position has moved since we opened the file (still
at 0 or not); it just returns the current position in the file, which is
known to the system directly without having to go ask anyone (it has to
be so, since each file descriptor has its own position).

I would be greatly surprised if fstat(), which has to go to the
directory (probably) to look up all the information on the file such as
ownership, permissions, etc., is faster.