mesos-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benjamin Mahler <benjamin.mah...@gmail.com>
Subject Re: Reaper related changes
Date Thu, 25 Apr 2013 18:43:10 GMT
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>
>>>>
>>>
>>>
>>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message