2017-01-05 10:35+0800, Peter Xu: > On Wed, Jan 04, 2017 at 03:55:42PM +0100, Radim Krčmář wrote: >> > I didn't notice the "-n" parameter for "wait", otherwise I won't >> > bother using SIGUSR1 at all. :) >> >> (Btw. why couldn't you use SIGCHLD?) > > My understanding: > > SIGCHLD is used by internal bash. For every command we write (like a > "ls" in the script), we should have forked another process to load the > "/bin/ls" binary, and when this command (in this case "ls") finishes, > it'll send one SIGCHLD to the main process. This should happen for > each non-builtin bash commands, and bash program is managing these > SIGCHLDs internally by default. So, we should not be able to trap > SIGCHLD in bash. > > There is one way to trap it, only if we provide: > > set -m > > to turn off the job controls of bash. I think that "-m" enables job control, but I didn't know it can be disabled. I don't understand what bash does with +m -- bg/fg/&/^Z work just as one would expect of job control, but not SIGCHLD. > However if with that, we'll > trigger the SIGCHLD handler for *every* task we run, even for the > normal commands like "ls". I suppose that's not what we want (we want > to only trap those background $QEMU processes). That's why I used > SIGUSR1 instead of SIGCHLD. I see, it is a more robust, but signals can race, so we couldn't depend on their count anyway. And wow, we really get SIGCHLD for foreground processes ... it wouldn't matter because the loop only uses builtins, but it is stupid. (I confess I don't usually use POSIX shells.) > Of course, after I know "wait -n", it becomes clumsy. :-) "clumsy" is still a praise for bash code. :) -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
