mesos-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Park <>
Subject Re: thread_local supported on Apple
Date Fri, 16 Dec 2016 19:11:21 GMT
Brief survey from the #dev channel:

Yosemite 10.10: Fail. Compilation error. (by @hausdorff
El Capitan 10.11: Fail. Compilation error. (by @zhitao
Sierra 10.12: Success (by @mpark)

On Wed, Dec 14, 2016 at 3:27 PM, Joris Van Remoortere <>

> The time has come and we finally have `thread_local` support in the Apple
> tool chain:
> eloperTools/RN-Xcode/Introduction.html
> In our code base we have a special exception for Apple that defines our
> thread local to be `__thread` rather than the c++11 standard
> `thread_local`.
> cc7eaab10efb499b6/3rdparty/stout/include/stout/thread_local.hpp
> A consequence of using `__thread` on Apple is that initializers for thread
> locals are required to be constant expressions. This is not the case for
> the c++11 standard `thread_local`.
> I would like to propose that we remove this exception on the Apple platform
> now that the Apple toolchain supports the c++11 standard.
> As I am not a common user of the Apple development experience I would like
> to ask for some input from the community as to whether requiring this
> toolchain update is acceptable, and if we need a deprecation period or if
> we can just make this change now.
> I am leaning towards no deprecation period as I am not aware of production
> environments running on systems that define `__APPLE__`.
> —
> *Joris Van Remoortere*
> Mesosphere

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