Paul D. Smith <[EMAIL PROTECTED]> wrote:
>If someone is interested in thinking about it, or engineering a
>solution, I'd be happy to discuss it and think about the best way to
>integrate it into the current implementation. I can provide some detail
>as to how exactly the UNIX version works for reference, and I have a few
>messages Rob Tulloh sent me back when we were doing the UNIX
>implementation discussing Windows-related issues I can forward to anyone
>who cares to look into this.
Thanks for the reply; I'm certainly interested in seeing correspondance that
you think might be appropriate.
I've started looking through the source code, and thinking about how it
would be implemented. My thinking at the moment is to create a Win32
Semaphore object, and pass a handle to this object to submakes, in much the
same was as the jobserver fds are passed now.
I have some thoughts:
When a new job can be started, the current jobserver implementation depends
on a blocking operation to acquire the right to start a job, or for SIGCHLD
to interrupt that operation. In the Win32 world, there is a primitive for
waiting for multiple events (WaitForMultipleObjects), which is currently
used in sub_proc.c to check for the death of a child, rather than Unix style
signals. My current thought is to modify sub_proc.c to provide an
additional function which will wait for the death of a child or a semaphore,
and call that from job.c. How this would relate to functions like
reap_children(), I don't really know.
The main question I have is about submakes releasing the right to start
additional jobs. Take the hypothetical case of a parent make starting two
submakes, with -j3: Initially, they compete for the right to start an
additional job. Assuming that the winning submake runs out of parallelism
and has a bunch of serial operations, can the Unix version release that
right to allow the other submake to become parallel if necessary? If so,
how; I can't see that in the code.
Using Win32 semaphores, submakes would need match releases with acquisitions
of the semaphore; this doesn't just happen on process death. Is there a
nice and clean way of doing this in the current code?
Jan Mikkelsen
