Re: Blocking child signals

[Zoltan Hidvegi <hzoli@cs.elte.hu>]

> It's possible you'd get a little performance, but I don't think it's
> worth the effort.  Signal blocking/unblocking shouldn't be a very time-
> consuming operation, except maybe for the old-style SYSV_SIGNALS or no-
> signal-blocking cases.

I remember that when signals were blocked instead of queued in mem.c and a
blocking/unblocking happened with each zalloc() zsh become more that 2 times
slower.  Of course zalloc() is called very often and in our case a similar
change may not have any noticable effect on the speed.

> I'd be willing to bet that the vast majority of those block/unblock pairs
> are happening in waitjob() and relatives, where zsh is in a loop doing

That's not the case when a cript use mostly builtins.

> It's important to block SIGCHLD signals not just before forking, but at
> any time you're going to manipulate the job table if any child is still
> executing.  You could add code to examine the job table and avoid making
> the system call when no children exist, but my guess is that would be
> just as expensive as simply making the call.

I was thinking about queueing the child signals somehow.  I started to
write something like that but in the end I gave up.  Also I'm not fully
convinced that the present code rules out all cases when the job table may
be changed unexpectedly by an unblocked child signal.

> The child blocking stuff corrected a whole bunch of zsh bugs, including
> (if I recall correctly) one where pipelines like "/bin/echo foo | less",
> where the first command exits very quickly, confused zsh into thinking
> the entire pipeline had exited, thus leaving "less" an orphan.

Yes, around a fork() blocking seems to be necessary.

Zoltan