On Mon, Jan 11, 2016 at 08:57:33AM +0100, Daniel Vetter wrote: > On Fri, Jan 08, 2016 at 08:44:29AM +0000, Chris Wilson wrote: > > Some stress tests create both the signal helper and a lot of competing > > processes. In these tests, the parent is just waiting upon the children, > > and the intention is not to keep waking up the waiting parent, but to > > keep interrupting the children (as we hope to trigger races in our > > kernel code). kill(-pid) sends the signal to all members of the process > > group, not just the target pid. > > I don't really have any clue about unix pgroups, but the -pid disappeared > compared to the previous version. -getppid(). I felt it was clearer to pass along the "negative pid = process group" after setting up the process group. > > We also switch from using SIGUSR1 to SIGCONT to paper over a race > > condition when forking children that saw the default signal action being > > run (and thus killing the child). > > I thought I fixed that race by first installing the new signal handler, > then forking. Ok, rechecked and it's the SYS_getpid stuff, so another > race. Still I thought signal handlers would survive a fork? So did irc. They didn't appear to as the children would sporadically die with SIGUSR1. -Chris -- Chris Wilson, Intel Open Source Technology Centre _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
