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




src/tests/command_executor_tests.cpp (lines 425 - 427)
<https://reviews.apache.org/r/55313/#comment233467>

    I'll fix up the spacing here, now that we've gotten rid of that absurdly 
long macro :)



src/tests/default_executor_tests.cpp (lines 442 - 444)
<https://reviews.apache.org/r/55313/#comment233466>

    Here too.


- Joseph Wu


On Jan. 18, 2017, 12:49 p.m., Alex Clemmer wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/55313/
> -----------------------------------------------------------
> 
> (Updated Jan. 18, 2017, 12:49 p.m.)
> 
> 
> Review request for mesos, Andrew Schwartzmeyer, Daniel Pravat, and Joseph Wu.
> 
> 
> Bugs: MESOS-6698, MESOS-6839 and MESOS-6870
>     https://issues.apache.org/jira/browse/MESOS-6698
>     https://issues.apache.org/jira/browse/MESOS-6839
>     https://issues.apache.org/jira/browse/MESOS-6870
> 
> 
> Repository: mesos
> 
> 
> Description
> -------
> 
> MESOS-6839 tracks a bug that causes the current implementation of the
> default executor to be unable to delete any processes associated with a
> task. To understand why requires some knowledge of the differences
> between the process model of Windows and Unix.
> 
> In Unix, there is a robust notion of a process tree, with a well-defined
> notion of process groups, sessions, signal delivery on the tree, and so
> on. Windows lacks a robust notion of a process hierarchy, and therefore
> largely has no equivalents to these constructs (including, notably,
> signal semantics).
> 
> One of the problems this mismatch causes Mesos is that it complicates
> the problem of killing a task, which is at its core a group of
> processes. On Windows, the easiest way to make a process and all its
> descendents easily killable is to track these processes in a Job Object,
> which is a Windows kernel construct similar in principle to Linux's
> control groups (though with different ideas of process namespacing).
> 
> There is some subtlety in making sure _all_ processes associated with a
> task are captured inside a Job Object. The most important consideration
> is that we need to make sure to add any process to the Job Object before
> it has a chance to create any child processes; if we fail to do this,
> the children will not be captured in the Job Object.
> 
> The solution to this is fairly simple on Windows. The process creation
> API allows users to trivially create a process in a suspended state, so
> that the Windows kernel scheduler does not schedule the process to run
> until the user explicitly resumes the main thread. This allows us to
> create the process and add it to a Job Object before it has a chance to
> create children, and then start the process.
> 
> This commit will accomplish this by changing `PosixLauncher::fork` to
> use the Subprocess parent hooks API, which implements exactly this
> semantics. Essentially, the launcher will launch the containerizer
> process, which will inspect the TaskInfo or the environment for a task
> to launch, and then launch it. Using the parent hooks API, Subprocess
> will create the containerizer process on Windows in a suspended state,
> and then the parent hook supplied by the launcher will add that process
> to a Job Object before it has a chance to run. Finally, Subprocess will
> mark the process as runnable, and return.
> 
> This commit resolves MESOS-6839. We also light up the executor tests, so
> it also resolves MESOS-6870 and MESOS-6839.
> 
> 
> Diffs
> -----
> 
>   src/slave/containerizer/mesos/launcher.cpp 
> a6a8c01cb39f35f8174fcb5af0ef18de2da5ee78 
>   src/tests/command_executor_tests.cpp 
> 4d5c21ec427ebaac053e56ae554cb466dfeb0b8b 
>   src/tests/default_executor_tests.cpp 
> ec3e854ed58a0fbb3bfad0bd21eb0e2974548865 
> 
> Diff: https://reviews.apache.org/r/55313/diff/
> 
> 
> Testing
> -------
> 
> 
> Thanks,
> 
> Alex Clemmer
> 
>

Reply via email to