🚀 go-pugleaf

There is a possible (on my machine, very probable) race condition bug
in GNU make, version 3.27.
Scene: start_job in commands.c forks. The forked job starts up, does
whatever it is supposed to do, and exits. The parent's signal handler
gets started.
Note that up to this point, the assignment "pid = vfork()" is not yet
completed, so that the signal handler does not find the child's entry.
Result: deadlock.
My temporary workaround (putting a sleep(1) before the execv() call)
confirmed this.
My final workaround was to use sigblock(). However, not every system
may have this.

I have another problem: sometimes make starts a complex shell command,
and then the shell just sits there and sleeps. I have no idea where this
might come from but I suspect that the signal handling of make sometimes
confuses its parents.

A few minor points:
- You should not signal(SIGCHLD,SIG_IGN). Use SIG_DFL instead.
  SIG_IGN will cause problems with some machines.
- _Please_ don't use #ifdef USG for every feature not found in vanilla Sys5.
  Feature-dependent flags (-DVFORK -DBSDSIGNALS) would have saved me
  from a few hours' work.

But aside from that, make seems to be an excellent program.