> On Nov. 18, 2012, 12:33 a.m., Ben Mahler wrote:
> > Great, this is all that's needed to fix MESOS-310 right?
> > 
> > Also, I recall some discussion about this bit of code already, in terms of 
> > where to place it, do you remember what the context was?

We wanted to split the launcher because it was being called both from the slave 
process and its forked process. I think we are fine now because all of the 
launcher code is being called inside the forked process.


- Vinod


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/8096/#review13541
-----------------------------------------------------------


On Nov. 16, 2012, 11:24 p.m., Vinod Kone wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/8096/
> -----------------------------------------------------------
> 
> (Updated Nov. 16, 2012, 11:24 p.m.)
> 
> 
> Review request for mesos, Benjamin Hindman and Ben Mahler.
> 
> 
> Description
> -------
> 
> Now, we do the executor setup (fetching etc) inside the forked process but 
> before assigning the process to its own cgroup.
> 
> This accomplishes two things:
> --> unblocks the cgroups isolation module from any potential hangs during 
> executor setup
> --> does not charge (for memory) the executor for the setup
> 
> 
> This addresses bug MESOS-310.
>     https://issues.apache.org/jira/browse/MESOS-310
> 
> 
> Diffs
> -----
> 
>   src/slave/cgroups_isolation_module.cpp 
> 8211618d7729350654e2d17946c5b912ed9dda6a 
>   src/slave/process_based_isolation_module.cpp 
> 16fd584e78db2c517d828f2576ab8a38c5ce57ad 
> 
> Diff: https://reviews.apache.org/r/8096/diff/
> 
> 
> Testing
> -------
> 
> sudo make check
> 
> 
> Thanks,
> 
> Vinod Kone
> 
>

Reply via email to