On Mon, 2014-05-19 at 18:47 +0300, Eli Zaretskii wrote: > > From: Paul Smith <[email protected]> > > Cc: Jan Hubicka <[email protected]>, [email protected] > > Date: Mon, 19 May 2014 11:05:45 -0400 > > > > I agree in principle: the read/write vs. semaphore etc. should be easy > > to abstract. However the added complexity of dealing with SIGCHLD > > handling while waiting on the pipe in POSIX might not be so simple to > > extract into a generic interface, given the complex behaviors in job.c. > > I believe this can be easily worked around by using a separate > thread. I think all this complexity is because SIGCHLD and its > handling serve as a kind of poor-man threading.
There's no question that you're right... if we're willing to change GNU make to require threads (which today it does not). Today GNU make can work on pretty much any ISO89/POSIX.1-conforming system with virtually all its functionality, which is a very low bar. I don't feel confident that (a) we should say make now requires a system with threading support and whatever locking capabilities that would be needed with it, or (b) we can ifdef out the requirement for threads without much more complexity, or (c) we can separate the jobserver implementation from the threading implementation. My main concern is whether it's possible to create a "process/job management" API separate from a "token management" API (both of which are really sorely needed) in such a way that we can mix and match, without basically replicating the current annoying interactions. _______________________________________________ Help-make mailing list [email protected] https://lists.gnu.org/mailman/listinfo/help-make
