[
https://issues.apache.org/jira/browse/MESOS-1102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13945139#comment-13945139
]
Till Toenshoff commented on MESOS-1102:
---------------------------------------
After some more evaluations and tests using Subprocess as is, I concluded that
there are more features needed. Hence I am now going to edit this ticket to
make it a collection point for the future of Subprocess as a whole.
Here are some of the additional features that I think would make sense.
h4.External pipe fd ownership
- Currently, Subprocess expects to have full ownership of the file descriptors
used for the pipes (stdin, stdout, stderr). There are applications of
subprocess that do not fit into this scheme and I would like to propose an
override that allows keeping the ownership of all or some of the pipe {{fd}}s
externally. In the end, we need to prevent Subprocess to assume those {{fd}}s
to be kept open until the process exits as some applications may need to close
the {{fd}}s earlier on.
h4.Skip exec'ing via /bin/sh
- Using {{/bin/sh -c}} for executing the child process may not be a good idea
as a whole. One reason would be the fact that /bin/sh is not deterministic. The
shell used depends on the distribution in use and/or on the preferences of the
system administrator. It may be bash, csh, dash etc...
- Another reason that I had painfully discovered is the fact that depending on
the shell configuration in use, child process pipe closing may or may not be
escalated back to the parent process. For example, when the child closes its
write-end of a pipe, depending on the shell configuration in use, that
{{close}} does not turn into an {{EOF}} on the parent, read-end of that pipe.
The shell itself keeps that pipe open until its child process has exited. I had
observed this on a Ubuntu 13.10 installation (Mesosphere's development
platform) but could not reproduce it on a VM installation of that same
distribution.
h4.Custom in-child execution lambda
- After reading the above discussion, I am still not convinced that
implementing such solution would be too harmful in relation to the flexibility
gain. My current angle on this is as follows; we will not be able to cover all
possible applications of an in-child function by predetermining and
implementing the respective overrides and their combinations. There will always
be a new application that is not covered, demanding a new override.
Additionally offering the most common applications via overrides (that make use
of the inchild-lambda) however might be a good idea.
> Further extensions to process::subprocess
> -----------------------------------------
>
> Key: MESOS-1102
> URL: https://issues.apache.org/jira/browse/MESOS-1102
> Project: Mesos
> Issue Type: Improvement
> Components: libprocess
> Affects Versions: 0.19.0
> Reporter: Till Toenshoff
> Assignee: Till Toenshoff
> Priority: Minor
> Labels: libprocess, subprocess
>
> I would like to propose the addition of a way to run a function within the
> forked child context to process::subprocess.
> The subprocess implementation is already extremely valuable and will allow us
> to remove many scattered, similar implementations within mesos once it is
> flexible enough.
> The recent addition (in review) of adding an environment map is just the
> right step into that direction.
> However, there still are areas, mostly within containerizer specifics that
> can not be replaced by the subprocess implementation as is, IMHO because
> running a function in the child context is missing. See e.g.
> /src/slave/containerizer/launcher.cpp,
> /src/slave/containerizer/mesos_containerizer.cpp and last but not least the
> pluggable_containerizer (in review).
> My envisioned approach would look something like this:
> {noformat}
> // Runs the provided command in a subprocess.
> // NOTE: Take extra care about the design of the inChild
> // lambda as it must not contain any async unsafe code.
> Try<Subprocess> subprocess(
> const std::string& command,
> const std::map<std::string, std::string>& env = std::map<std::string,
> std::string>(),
> const lambda::function<void()>& inChild = NULL);
> {noformat}
> Example usage:
> {noformat}
> struct ChildFunction {
> ChildFunction(const string& directory) : directory(directory) {};
> void operator ()()
> {
> if (::chdir(directory) < 0) {
> ABORT("Failed to chdir");
> }
> }
> const string& directory;
> };
> Try<Subprocess> external = subprocess(
> "foo",
> map<string, string>(),
> ChildFunction("bar");
> {noformat}
> Please let me know what you think about this or if I was on a wrong track.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
