You are viewing a plain text version of this content. The canonical link for it is here.
Posted to reviews@mesos.apache.org by Joris Van Remoortere <jo...@gmail.com> on 2015/09/09 19:16:32 UTC
Re: Review Request 37876: stout: Replace GCC intrinsics with
std::atomic.
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/37876/#review98209
-----------------------------------------------------------
Ship it!
Thanks for cleaning this all up Neil!
Let's add some style-guide info or reference the google style-guide if your changes are already covered.
A few concise examples would be great.
3rdparty/libprocess/3rdparty/stout/include/stout/os/posix/fork.hpp (line 278)
<https://reviews.apache.org/r/37876/#comment154504>
Some places in this review chain you use the provided typedefs `std::atomic_XXX`, whereas elsewhere you provide the explicit specialization `std::atomic<int64_t>`.
Can you put a review at the front of this chain to provide guidance for consistency in the style guide regarding atomics? I would add examples and policies for:
1. Always using the explicit specializations; or when to use the typedef over the explicit (if you have a good argument for that)
2. Why we use the explicit functions such as `store(X)` as opposed to the `operator=` as we discussed in person.
Once that's done, please make any changes required in the chain to stay consistent.
- Joris Van Remoortere
On Sept. 9, 2015, 4:02 p.m., Neil Conway wrote:
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/37876/
> -----------------------------------------------------------
>
> (Updated Sept. 9, 2015, 4:02 p.m.)
>
>
> Review request for mesos, Joris Van Remoortere and switched to 'mcypark'.
>
>
> Bugs: MESOS-3326
> https://issues.apache.org/jira/browse/MESOS-3326
>
>
> Repository: mesos
>
>
> Description
> -------
>
> MESOS-3326.
>
>
> Diffs
> -----
>
> 3rdparty/libprocess/3rdparty/stout/include/stout/os/posix/fork.hpp d43433aeab5a1a68ff76eb75416672fae456c70d
>
> Diff: https://reviews.apache.org/r/37876/diff/
>
>
> Testing
> -------
>
> make check
>
>
> Thanks,
>
> Neil Conway
>
>
Re: Review Request 37876: stout: Replace GCC intrinsics with
std::atomic.
Posted by Neil Conway <ne...@gmail.com>.
> On Sept. 9, 2015, 5:16 p.m., Joris Van Remoortere wrote:
> > 3rdparty/libprocess/3rdparty/stout/include/stout/os/posix/fork.hpp, line 278
> > <https://reviews.apache.org/r/37876/diff/1/?file=1057697#file1057697line278>
> >
> > Some places in this review chain you use the provided typedefs `std::atomic_XXX`, whereas elsewhere you provide the explicit specialization `std::atomic<int64_t>`.
> >
> > Can you put a review at the front of this chain to provide guidance for consistency in the style guide regarding atomics? I would add examples and policies for:
> > 1. Always using the explicit specializations; or when to use the typedef over the explicit (if you have a good argument for that)
> > 2. Why we use the explicit functions such as `store(X)` as opposed to the `operator=` as we discussed in person.
> >
> > Once that's done, please make any changes required in the chain to stay consistent.
Thanks for the review, Joris!
This is a great point -- I'll update the style guide. As far as when to use the explicit specialization over the typedef, I only used an explicit specialization when C++11 doesn't provide a typedef. e.g., C++ doesn't provide std::atomic_int64_t, so I used std::atomic<int64_t> (the standard provides std::atomic_fast_int64_t, which seems a bit painful to type/read). I don't have strong feelings here, though: for example, you could argue that we should always use the explicit specializations for the sake of consistency.
- Neil
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/37876/#review98209
-----------------------------------------------------------
On Sept. 9, 2015, 4:02 p.m., Neil Conway wrote:
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/37876/
> -----------------------------------------------------------
>
> (Updated Sept. 9, 2015, 4:02 p.m.)
>
>
> Review request for mesos, Joris Van Remoortere and switched to 'mcypark'.
>
>
> Bugs: MESOS-3326
> https://issues.apache.org/jira/browse/MESOS-3326
>
>
> Repository: mesos
>
>
> Description
> -------
>
> MESOS-3326.
>
>
> Diffs
> -----
>
> 3rdparty/libprocess/3rdparty/stout/include/stout/os/posix/fork.hpp d43433aeab5a1a68ff76eb75416672fae456c70d
>
> Diff: https://reviews.apache.org/r/37876/diff/
>
>
> Testing
> -------
>
> make check
>
>
> Thanks,
>
> Neil Conway
>
>