Re: patch to support output synchronization under -j

[David Boyce]

On Thu, Apr 14, 2011 at 2:10 PM, Paul Smith <address@hidden> wrote:
> There is no specific region of the file that's locked: the lockfile is
> basically a file-based, system-wide semaphore.

Yes, it's conceptually a semaphore. In fact a Windows port might
prefer to use real semaphores. The reason I stayed away from them on
the POSIX side is that, according to my reading, POSIX semaphores
don't go away automatically when the creating process exits; they need
to be explicitly released. Which entails a lot of responsibility and
complexity in terms of signal handling and so on. An exclusive file
lock produces the same result but goes away with its file descriptor.
File locking is also older and thus likely a little more portable,
though both are pretty old.

> The entire file is [...] empty and has no content.

That's not actually the case with the current implementation. The file
can have content, in fact the obvious candidate is often the Makefile
as shown in the test case. It must be writable according to  fcntl
locking semantics but it is never written to.

> I'm not sure I like the idea of having to define a lockfile to enable
> this feature though.  It feels a little too much like exposing the
> implementation details to the user.

Agree. This needs a little more thought.

David