On Mon, 2018-07-23 at 07:10 +0200, Barath Aron wrote: > On 07/22/2018 09:58 PM, Paul Smith wrote: > > On Mon, 2018-07-09 at 09:05 +0200, Aron Barath wrote: > > > --- > > > > Thanks for the work you put into this! > > You're welcome! :) > > Unfortunately this change reveals some deeper problems that I will > > need to address. Basically, the old code never really expected > > fork() to fail: if it did we intended to just give up completely. > > Thus, it expected child_execute_job() to always succeed except in > > exceptional situations, where make itself was not able to continue. > > That's good news and bad news.
This weekend I reworked the handling of failures in child_execute_job() so that it behaves properly even when the child failure happens in the current process (e.g., the fork() or posix_spawn()). It needs a bit of cleanup--in particular writing a test is complicated by the fact that errors currently have different formats when built with fork() vs. posix_spawn(). I need to decide if I want to align them or fix the test to understand the difference. I also added a configure --disable-posix-spawn option for those who want to continue to use fork()/vfork() even when posix_spawn() is available. Since there's one missing bit of functionality in the posix_spawn() case (resetting the stack size in the child) and I don't think that using posix_spawn() buys you much if anything over vfork() in GNU/Linux, at least. _______________________________________________ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
