Re: Review Request 37876: stout: Replace GCC intrinsics with std::atomic.

[Neil Conway]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/37876/
---

(Updated Sept. 10, 2015, 6:53 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 (updated)
-

  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.

[Joris Van Remoortere]

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


Some places in this review chain you use the provided typedefs 
`std::atomic_XXX`, whereas elsewhere you provide the explicit specialization 
`std::atomic`.

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.

[Neil Conway]

> On Sept. 9, 2015, 5:16 p.m., Joris Van Remoortere wrote:
> > 3rdparty/libprocess/3rdparty/stout/include/stout/os/posix/fork.hpp, line 278
> > 
> >
> > Some places in this review chain you use the provided typedefs 
> > `std::atomic_XXX`, whereas elsewhere you provide the explicit 
> > specialization `std::atomic`.
> > 
> > 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 (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
> 
>