> On Aug. 5, 2014, 12:30 a.m., Ian Downes wrote: > > 3rdparty/libprocess/src/tests/reap_tests.cpp, lines 154-158 > > <https://reviews.apache.org/r/24270/diff/2/?file=651304#file651304line154> > > > > Why not merge these loops? i.e., reap the pid then sigkill it > > immediately, then you can drop childPid.
The intent here was the get as much "stacking" of notifications as possible. e.g., create and reap all child pids, let the new processes settle (which I have not done), then kill the children. I should add a wait completion of some kind prior to the kill. I believe that this creates too many races if we create/reap/kill each pid serially - e.g., this is about generating worst-case performance in the reap wait loop. - Craig ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/24270/#review49541 ----------------------------------------------------------- On Aug. 4, 2014, 11:23 p.m., Craig Hansen-Sturm wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/24270/ > ----------------------------------------------------------- > > (Updated Aug. 4, 2014, 11:23 p.m.) > > > Review request for mesos and Ian Downes. > > > Bugs: MESOS-1669 > https://issues.apache.org/jira/browse/MESOS-1669 > > > Repository: mesos-git > > > Description > ------- > > New test added which serves as a performance test for reaping. This test > forks N children (default value is 4), kills these children, and then uses > process::collect to collect all status results. This is a simple > generalization of the existing ChildProcess test, except that it is realtime > (as required for profiling), e.g., no clock manipulation is performed. This > test is also useful for stressing the collect.hpp interfaces. > > > Diffs > ----- > > 3rdparty/libprocess/src/tests/reap_tests.cpp a18d54c > > Diff: https://reviews.apache.org/r/24270/diff/ > > > Testing > ------- > > make check > > > Thanks, > > Craig Hansen-Sturm > >
