[jira] [Commented] (MESOS-943) Provide an abstraction for asynchronous launching of subprocesses.

["Ian Downes (JIRA)" <ji...@apache.org>]

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

Ian Downes commented on MESOS-943:
----------------------------------

Could you clarify the reasoning behind moving the Reaper into libprocess: is it just a better place to have it or are there some requirements necessitating it?


> Provide an abstraction for asynchronous launching of subprocesses.
> ------------------------------------------------------------------
>
>                 Key: MESOS-943
>                 URL: https://issues.apache.org/jira/browse/MESOS-943
>             Project: Mesos
>          Issue Type: Improvement
>            Reporter: Benjamin Mahler
>            Assignee: Benjamin Mahler
>
> This has come up during [~idownes] changes to add containerization.
> We would like to be able to run commands asynchronously like:
> {{curl -O http://foo.com/bigfile.zip}}
> Currently, there is not an easy way to do this while having:
> 1. A Future handle on the exit status of the subprocess.
> 2. The means to 'discard' the future and consequently kill the subprocess (e.g. stalled hadoop command).
> 3. Handles to stdin, stdout, stderr of the subprocess.
> The first issue is that we need to re-work the Reaper to not reap _all_ subprocesses. Rather, we need to allow other components to reap their own forked subprocesses without the slave's Reaper "stealing" the exit status information. I've proposed that we move the Reaper into libprocess initially with the only change being to reap the desired pids. (We can optimize this later using a per-pid blocking thread or SIGCHLD).
> One concern is that if we 'leak' child processes by accidentally not reaping, we may fill the process table with zombie processes. However, we have tight control over where our code performs forks, and can enforce proper reaping.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)