> On Oct. 17, 2015, 8:43 p.m., Joris Van Remoortere wrote:
> > 3rdparty/libprocess/include/process/owned.hpp, line 82
> > <https://reviews.apache.org/r/39330/diff/1/?file=1098561#file1098561line82>
> >
> >     Wish we could use `nullptr`, but we currently only allow `NULL` for now.
> >     Here and below.

Sure, easy to fix. I'm curious -- why is nullptr disallowed? (It has been 
supported since GCC 4.6...)


- Neil


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


On Oct. 14, 2015, 10:29 p.m., Neil Conway wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/39330/
> -----------------------------------------------------------
> 
> (Updated Oct. 14, 2015, 10:29 p.m.)
> 
> 
> Review request for mesos and Joris Van Remoortere.
> 
> 
> Bugs: MESOS-3326
>     https://issues.apache.org/jira/browse/MESOS-3326
> 
> 
> Repository: mesos
> 
> 
> Description
> -------
> 
> See MESOS-3326. We adopted std::atomic in most of the code base earlier 
> (commits
> 87de003c6e8a, 4b938052b6af, and 4a01850c5540), but a few places were omitted;
> those locations are fixed by this commit.
> 
> There's one remaining place to improve: we use the GCC intrinsic
> __sync_synchronize() in 3rdparty/libprocess/include/process/logging.h. Because
> that is used to protect modifications to the FLAGS_v variable defined by glog,
> we can't easily adapt it to use std::atomic.
> 
> 
> Diffs
> -----
> 
>   3rdparty/libprocess/include/process/owned.hpp 
> bc5b527152c8864544ad58070c0bfc81639056da 
>   3rdparty/libprocess/include/process/shared.hpp 
> 021807b961bb55f11c9e04327135bd83f4d86c21 
>   3rdparty/libprocess/src/tests/process_tests.cpp 
> e5277de5b5bdea4a44606cda7fbf69a559aeebbe 
> 
> Diff: https://reviews.apache.org/r/39330/diff/
> 
> 
> Testing
> -------
> 
> make check
> 
> 
> Thanks,
> 
> Neil Conway
> 
>

Reply via email to