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. _______________________________________________ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make