mesos-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig Hansen-Sturm" <cr...@mesosphere.io>
Subject Re: Review Request 24270: New MultiChildProcess test added to reap_tests.cpp
Date Tue, 05 Aug 2014 23:17:05 GMT


> 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
> 
>


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message