> Date: Fri, 19 Apr 2013 11:54:05 +0200
> Cc: bo...@kolpackov.net, bug-make@gnu.org
> From: Frank Heckenbach <f.heckenb...@fh-soft.de>
>
> Eli Zaretskii wrote:
>
> > Initial investigation indicates that tmpfile should do the job just
> > fine: the file is deleted only when the last descriptor for it is
> > closed. That includes any duplicated descriptors.
>
> Great.
>
> > As for fcntl, F_SETLKW, and F_GETFD, they will need to be emulated.
> > In particular, it looks like LockFileEx with LOCKFILE_EXCLUSIVE_LOCK
> > flag set and LOCKFILE_FAIL_IMMEDIATELY flag cleared should do the
> > job. I will need to see how it works in reality, though.
>
> OK.
Upon a second look, I'm not sure I understand how this feature works,
exactly, and why you-all thought making it work on Windows is a matter
of a few functions. I sincerely hope I'm missing something, please
bear with me.
First, most of the meat of OUTPUT_SYNC code, which sets up the stage
when running child jobs, is in a branch that isn't compiled on Windows
("#if !defined(__MSDOS__) && !defined(_AMIGA) && !defined(WINDOWS32)"
on line 1482 of job.c). So currently that part is not even run on
Windows. Please tell me that nothing in this feature relies on
'fork', with its copying of handles and other data structures.
Because if it does, we have no hope of making it work on Windows, at
least not using the same algorithms as on Unix.
More importantly, how exactly locking the (redirected) stdout/stderr
of the child is supposed to cause synchronization, and why do we need
it at all? Isn't synchronization already achieved by redirecting
child's output to a file, and only dumping it to screen when the child
exits? What does lock add to this? Who else will be writing what to
where, that we want to prevent by holding the lock/semaphore?
In an old thread, Paul explained something similar:
> David, can you explain why you needed to lock the files? Also, what
> region(s) of the file you are locking? fcntl with F_WRLCK won't work
> on Windows, so the question is how to emulate it.
David wants to interlock between ALL instances of make printing output,
so that even during recursive makes no matter how many you have running
concurrently, only one will print its output at a time.
There is no specific region of the file that's locked: the lockfile is
basically a file-based, system-wide semaphore. The entire file is
"locked"; it's empty and has no content.
Assuming this all is still basically true, I guess I still don't
understand what exactly is being locked and why. E.g., why do we only
want to interlock instances of Make, but not the programs they run?
Also, acquire_semaphore is used only in sync_output, which is called
only when a child exits. IOW, nothing is locked while the child
runs, only when its output is ready.
In addition, we are locking stdout. But doesn't each instance of Make
have, or can have, its own stdout? If so, how will the interlock
work?
What am I missing? Probably a lot.
TIA
_______________________________________________
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make
