Mailing-List: contact mesos-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: mesos-dev@incubator.apache.org
Received-SPF: pass (nike.apache.org: domain of benjamin.mahler@gmail.com
 designates 209.85.212.41 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <9C09F23C-87E0-48DC-AEA4-6EAB6341BC10@gmail.com>
References: 
 <CAA48Z=Wbk2thve_PskGbQ4wESuK5aYqC-P-JG5P-rGHYRcSWqw@mail.gmail.com>
 <CA+8RcoRBpWEBeXzfsH3_rSPZEeQoe=Pw7-mX=A3nse_umz3NTQ@mail.gmail.com>
 <CAAkWvAyCmnmpxyEEqb3RmWOQU8Z7Yd6Q1VjJtv+==Dn1Vs4_rw@mail.gmail.com>
 <CAA48Z=WQvW8GCOtpgLQi4sRn3KfdJz__-WGdJTq=p3bzMCSVbw@mail.gmail.com>
 <CA+8RcoTC7Ce7_bUeNwtd7Pw2SY3zuoEBS6L+opDjS4=t3W2GXQ@mail.gmail.com>
 <9C09F23C-87E0-48DC-AEA4-6EAB6341BC10@gmail.com>
From: Benjamin Mahler <benjamin.mahler@gmail.com>
Date: Thu, 25 Apr 2013 13:41:55 -0700
Message-ID: 
 <CA+8RcoS1F56efghXZCzsj8SoMYRKDwJ7JcX_tTVTyvz1Xs1BTw@mail.gmail.com>
Subject: Re: Reaper related changes
To: Benjamin Hindman <benjamin.hindman@gmail.com>
Cc: Benjamin Mahler <benjamin.mahler@gmail.com>, Yan Xu <yan@twitter.com>,
	Vinod Kone <vinod@twitter.com>,
	"mesos-dev@incubator.apache.org" <mesos-dev@incubator.apache.org>
Content-Type: multipart/alternative; boundary=001a11c2bd123a85ef04db3574cb

--001a11c2bd123a85ef04db3574cb
Content-Type: text/plain; charset=ISO-8859-1

Ok so linux/proc.hpp currently has:

Try<std::set<pid_t> > pids();
Try<std::set<pid_t> > children(pid_t pid, bool recursive = true);
Try<ProcessStatus> status(pid_t pid);

We want these to work for OSX as well for now.

Say we move linux/proc.{cpp,hpp} into stout/proc.hpp, then we can move
alive into os and fail the compilation if anyone includes stout/proc.hpp
without __linux__ defined.

We'll also want os::pids(), os::children(pid_t) and os::status(pid_t) for
non-linux systems. I originally wanted to have these call into
stout/proc.hpp for linux, but that introduces a circular dependency.


On Thu, Apr 25, 2013 at 11:51 AM, Benjamin Hindman <
benjamin.hindman@gmail.com> wrote:

> I like os:: a lot. I think the type signature (i.e., taking a pid_t) is
> sufficient for disambiguation.
>
>
>
>
>
> On Apr 25, 2013, at 11:43 AM, Benjamin Mahler <benjamin.mahler@gmail.com>
> wrote:
>
> We also have a src/common/process_utils.hpp which contains only
> mesos::internal::utils::process::killtree() at the moment.
>
>
> On Thu, Apr 25, 2013 at 11:37 AM, Yan Xu <yan@twitter.com> wrote:
>
>> I guess os:: is fine, but in a separate file?
>>
>> --
>> Jiang Yan Xu <yan@twitter.com> @xujyan <http://twitter.com/xujyan>
>>
>>
>> On Thu, Apr 25, 2013 at 11:29 AM, Vinod Kone <vinod@twitter.com> wrote:
>>
>>> I don't like process:: because it conflicts with the libprocess
>>> namespace as you mentioned.
>>>
>>> I still like proc:: but clearly BenH doesn't like it. I'm ok with os::
>>> namespace.
>>>
>>>
>>> @vinodkone
>>>
>>>
>>> On Thu, Apr 25, 2013 at 11:19 AM, Benjamin Mahler <
>>> benjamin.mahler@gmail.com> wrote:
>>>
>>>> Is there any consensus on how to place process utilities in stout? I
>>>> would expect this to be in a process:: namespace but of course that is
>>>> confusing because we use libprocess, which should perhaps have a
>>>> libprocess:: namespace instead..
>>>>
>>>> I'll be moving process utilities etc into stout, hopefully with the
>>>> same calls for linux and OSX but I'm not yet certain if that is possible. I
>>>> would like to place these in a process.hpp file inside a process::
>>>> namespace.
>>>>
>>>> I think these read very nicely:
>>>> process::alive(pid_t)
>>>> process::children(pid_t)
>>>> process::stat(pid_t)
>>>>
>>>> Thoughts?
>>>>
>>>>
>>>> On Tue, Apr 23, 2013 at 6:29 PM, Yan Xu <yan@jxu.me> wrote:
>>>>
>>>>> This batch of commits changed the reaper to use "Future" as the
>>>>> notification mechanism.
>>>>>
>>>>> Sequence:
>>>>> https://reviews.apache.org/r/10744/
>>>>> https://reviews.apache.org/r/10745/
>>>>> https://reviews.apache.org/r/10746/
>>>>> https://reviews.apache.org/r/10747/
>>>>>
>>>>> Best,
>>>>> Yan
>>>>> --
>>>>> Jiang Yan Xu <yan@twitter.com> @xujyan <http://twitter.com/xujyan>
>>>>>
>>>>
>>>>
>>>
>>
>

--001a11c2bd123a85ef04db3574cb--