You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mesos.apache.org by "Till Toenshoff (JIRA)" <ji...@apache.org> on 2014/04/04 02:00:24 UTC

[jira] [Commented] (MESOS-1102) Further extensions to process::subprocess

    [ https://issues.apache.org/jira/browse/MESOS-1102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13959452#comment-13959452 ] 

Till Toenshoff commented on MESOS-1102:
---------------------------------------

commit c313c71ac5aa690abe1ec17aaf5050fb342ed81d
Author: Till Toenshoff <to...@me.com>
Date:   Thu Apr 3 16:24:54 2014 -0700

    Adds a "setup" function to process::subprocess.
    
    Adds the ability run a "setup" function to process::subprocess within
    the forked child context, after fork and before exec.
    
    NOTE: Such lambda must not contain any async unsafe code. For details
    on async safety, see POSIX.1-2004 on async-signal-safe functions, also
    referenced in the signal man-pages:
    http://man7.org/linux/man-pages/man7/signal.7.html.
    
    Review: https://reviews.apache.org/r/19259

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