Re: thread_local supported on Apple

[Joris Van Remoortere]

__thread is a compiler intrinsic and not part of the standard.
thread_local was introduced in the c++11 standard.
Until recently the default version of clang shipped on the apple platform
was not in compliance with the c++11 standard because the team saw an
opportunity for a higher performance implementation of thread local storage
specifically on the Apple platform. The fact that the compiler was then not
standard compliant meant we had to do some tricks like the conditional
compilation you see in stout.

thread_local is more accepting in terms of its initialization. A developer
may write some code that uses this (standard compliant) feature and only
later realize that it doesn't compile on certain other Developers' systems.

I would love to move towards a more consistent and standard compliant
code-base that reduces frustration for developers shipping code. If the
burden is not too high for current developers on Apple systems then this is
a pretty easy fix :-)

Joris

—
*Joris Van Remoortere*
Mesosphere

On Tue, Dec 20, 2016 at 5:02 PM, Vinod Kone  wrote:

> 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`.
>
> Can you expand on the benefits of 'thread_local'? Is the above statement
> alluding to tech debt or preventing new features or performance?
>
>
>
> @vinodkone
>
> > On Dec 20, 2016, at 7:04 PM, Michael Park  wrote:
> >
> > Joris, I don't have a strong stance here. I was just providing a data
> point
> > of what people may experience out of the box.
> >
> > Am I correct in understanding the following implications?
> >  - 10.10 would require brew-installed clang to work
> >  - 10.11 would require a Xcode upgrade
> >  - 10.12 would work out of the box
> >
> >> On Mon, Dec 19, 2016 at 6:27 PM, James Peach  wrote:
> >>
> >>
> >>> On Dec 19, 2016, at 3:00 PM, Joris Van Remoortere  >
> >> wrote:
> >>>
> >>> Thanks for your input Zameer.
> >>>
> >>> Is it common for developers on mac to use XCode as their compilation
> >>> environment as well? I would think if you used clang on the command
> line
> >>> then you could still install an updated version of clang without having
> >> to
> >>> do a system upgrade from Yosemite?
> >>
> >> Xcode provides both the integrated development environment (typically
> not
> >> used with Mesos) and one or more toolchains and SDKs (used by Mesos).
> >> Whether the modern toolchain can be used with an older release depends
> on
> >> whether the Xcode release is considered supported on that release.
> >>
> >>>
> >>> I'm getting the impression that it's reasonable to make this change
> >> without
> >>> a deprecation cycle. Please let me know if you (anyone) disagrees.
> >>>
> >>> —
> >>> *Joris Van Remoortere*
> >>> Mesosphere
> >>>
>  On Mon, Dec 19, 2016 at 2:17 PM, Zameer Manji 
> wrote:
> 
>  I believe this thread_local support is in XCode 8.2. From the link you
>  shared:
> 
> > Xcode 8.2 requires a Mac running macOS 10.11.5 or later
> 
>  This means that users can upgrade the compiler on El Capitan just fine
>  without a system upgrade.
> 
>  Users on Yosemite need to do a system upgrade to pick up the new
> >> compiler
>  however.
> 
>  On Mon, Dec 19, 2016 at 12:33 PM, Joris Van Remoortere <
>  jo...@mesosphere.io>
>  wrote:
> 
> > Is my understanding incorrect regarding the ability to upgrade the
>  compiler
> > version on Yosemite and El Capitan without requiring a full system
>  upgrade?
> >
> > @Mpark are you making a case for not updating to `thread_local` just
> >> yet?
> >
> > —
> > *Joris Van Remoortere*
> > Mesosphere
> >
> > On Fri, Dec 16, 2016 at 11:11 AM, Michael Park 
> >> wrote:
> >
> >> Brief survey from the #dev channel: https://mesos.slack.com/
> >> archives/dev/p1481760285000430
> >>
> >> Yosemite 10.10: Fail. Compilation error. (by @hausdorff
> >> https://mesos.slack.com/archives/dev/p1481760552000435)
> >> El Capitan 10.11: Fail. Compilation error. (by @zhitao
> >> https://mesos.slack.com/files/zhitao/F3F7WUCNM/-.diff)
> >> Sierra 10.12: Success (by @mpark)
> >>
> >> On Wed, Dec 14, 2016 at 3:27 PM, Joris Van Remoortere <
> > jo...@mesosphere.io
> >>>
> >> wrote:
> >>
> >>> The time has come and we finally have `thread_local` support in the
> > Apple
> >>> tool chain:
> >>> https://developer.apple.com/library/content/releasenotes/Dev
> >>> 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`.
> >>> 

Re: thread_local supported on Apple

[Vinod Kone]

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`.

Can you expand on the benefits of 'thread_local'? Is the above statement 
alluding to tech debt or preventing new features or performance?



@vinodkone

> On Dec 20, 2016, at 7:04 PM, Michael Park  wrote:
> 
> Joris, I don't have a strong stance here. I was just providing a data point
> of what people may experience out of the box.
> 
> Am I correct in understanding the following implications?
>  - 10.10 would require brew-installed clang to work
>  - 10.11 would require a Xcode upgrade
>  - 10.12 would work out of the box
> 
>> On Mon, Dec 19, 2016 at 6:27 PM, James Peach  wrote:
>> 
>> 
>>> On Dec 19, 2016, at 3:00 PM, Joris Van Remoortere 
>> wrote:
>>> 
>>> Thanks for your input Zameer.
>>> 
>>> Is it common for developers on mac to use XCode as their compilation
>>> environment as well? I would think if you used clang on the command line
>>> then you could still install an updated version of clang without having
>> to
>>> do a system upgrade from Yosemite?
>> 
>> Xcode provides both the integrated development environment (typically not
>> used with Mesos) and one or more toolchains and SDKs (used by Mesos).
>> Whether the modern toolchain can be used with an older release depends on
>> whether the Xcode release is considered supported on that release.
>> 
>>> 
>>> I'm getting the impression that it's reasonable to make this change
>> without
>>> a deprecation cycle. Please let me know if you (anyone) disagrees.
>>> 
>>> —
>>> *Joris Van Remoortere*
>>> Mesosphere
>>> 
 On Mon, Dec 19, 2016 at 2:17 PM, Zameer Manji  wrote:
 
 I believe this thread_local support is in XCode 8.2. From the link you
 shared:
 
> Xcode 8.2 requires a Mac running macOS 10.11.5 or later
 
 This means that users can upgrade the compiler on El Capitan just fine
 without a system upgrade.
 
 Users on Yosemite need to do a system upgrade to pick up the new
>> compiler
 however.
 
 On Mon, Dec 19, 2016 at 12:33 PM, Joris Van Remoortere <
 jo...@mesosphere.io>
 wrote:
 
> Is my understanding incorrect regarding the ability to upgrade the
 compiler
> version on Yosemite and El Capitan without requiring a full system
 upgrade?
> 
> @Mpark are you making a case for not updating to `thread_local` just
>> yet?
> 
> —
> *Joris Van Remoortere*
> Mesosphere
> 
> On Fri, Dec 16, 2016 at 11:11 AM, Michael Park 
>> wrote:
> 
>> Brief survey from the #dev channel: https://mesos.slack.com/
>> archives/dev/p1481760285000430
>> 
>> Yosemite 10.10: Fail. Compilation error. (by @hausdorff
>> https://mesos.slack.com/archives/dev/p1481760552000435)
>> El Capitan 10.11: Fail. Compilation error. (by @zhitao
>> https://mesos.slack.com/files/zhitao/F3F7WUCNM/-.diff)
>> Sierra 10.12: Success (by @mpark)
>> 
>> On Wed, Dec 14, 2016 at 3:27 PM, Joris Van Remoortere <
> jo...@mesosphere.io
>>> 
>> wrote:
>> 
>>> The time has come and we finally have `thread_local` support in the
> Apple
>>> tool chain:
>>> https://developer.apple.com/library/content/releasenotes/Dev
>>> 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`.
>>> https://github.com/apache/mesos/blob/812e5e3d4e4d9e044a1cfe6
>>> 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
>>> 
>> 
> 
> --
> Zameer Manji
> 
 
>> 
>> 

Re: thread_local supported on Apple

[Michael Park]

Joris, I don't have a strong stance here. I was just providing a data point
of what people may experience out of the box.

Am I correct in understanding the following implications?
  - 10.10 would require brew-installed clang to work
  - 10.11 would require a Xcode upgrade
  - 10.12 would work out of the box

On Mon, Dec 19, 2016 at 6:27 PM, James Peach  wrote:

>
> > On Dec 19, 2016, at 3:00 PM, Joris Van Remoortere 
> wrote:
> >
> > Thanks for your input Zameer.
> >
> > Is it common for developers on mac to use XCode as their compilation
> > environment as well? I would think if you used clang on the command line
> > then you could still install an updated version of clang without having
> to
> > do a system upgrade from Yosemite?
>
> Xcode provides both the integrated development environment (typically not
> used with Mesos) and one or more toolchains and SDKs (used by Mesos).
> Whether the modern toolchain can be used with an older release depends on
> whether the Xcode release is considered supported on that release.
>
> >
> > I'm getting the impression that it's reasonable to make this change
> without
> > a deprecation cycle. Please let me know if you (anyone) disagrees.
> >
> > —
> > *Joris Van Remoortere*
> > Mesosphere
> >
> > On Mon, Dec 19, 2016 at 2:17 PM, Zameer Manji  wrote:
> >
> >> I believe this thread_local support is in XCode 8.2. From the link you
> >> shared:
> >>
> >>> Xcode 8.2 requires a Mac running macOS 10.11.5 or later
> >>
> >> This means that users can upgrade the compiler on El Capitan just fine
> >> without a system upgrade.
> >>
> >> Users on Yosemite need to do a system upgrade to pick up the new
> compiler
> >> however.
> >>
> >> On Mon, Dec 19, 2016 at 12:33 PM, Joris Van Remoortere <
> >> jo...@mesosphere.io>
> >> wrote:
> >>
> >>> Is my understanding incorrect regarding the ability to upgrade the
> >> compiler
> >>> version on Yosemite and El Capitan without requiring a full system
> >> upgrade?
> >>>
> >>> @Mpark are you making a case for not updating to `thread_local` just
> yet?
> >>>
> >>> —
> >>> *Joris Van Remoortere*
> >>> Mesosphere
> >>>
> >>> On Fri, Dec 16, 2016 at 11:11 AM, Michael Park 
> wrote:
> >>>
>  Brief survey from the #dev channel: https://mesos.slack.com/
>  archives/dev/p1481760285000430
> 
>  Yosemite 10.10: Fail. Compilation error. (by @hausdorff
>  https://mesos.slack.com/archives/dev/p1481760552000435)
>  El Capitan 10.11: Fail. Compilation error. (by @zhitao
>  https://mesos.slack.com/files/zhitao/F3F7WUCNM/-.diff)
>  Sierra 10.12: Success (by @mpark)
> 
>  On Wed, Dec 14, 2016 at 3:27 PM, Joris Van Remoortere <
> >>> jo...@mesosphere.io
> >
>  wrote:
> 
> > The time has come and we finally have `thread_local` support in the
> >>> Apple
> > tool chain:
> > https://developer.apple.com/library/content/releasenotes/Dev
> > 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`.
> > https://github.com/apache/mesos/blob/812e5e3d4e4d9e044a1cfe6
> > 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
> >
> 
> >>>
> >>> --
> >>> Zameer Manji
> >>>
> >>
>
>

Re: thread_local supported on Apple

[James Peach]

> On Dec 19, 2016, at 3:00 PM, Joris Van Remoortere  wrote:
> 
> Thanks for your input Zameer.
> 
> Is it common for developers on mac to use XCode as their compilation
> environment as well? I would think if you used clang on the command line
> then you could still install an updated version of clang without having to
> do a system upgrade from Yosemite?

Xcode provides both the integrated development environment (typically not used 
with Mesos) and one or more toolchains and SDKs (used by Mesos). Whether the 
modern toolchain can be used with an older release depends on whether the Xcode 
release is considered supported on that release.

> 
> I'm getting the impression that it's reasonable to make this change without
> a deprecation cycle. Please let me know if you (anyone) disagrees.
> 
> —
> *Joris Van Remoortere*
> Mesosphere
> 
> On Mon, Dec 19, 2016 at 2:17 PM, Zameer Manji  wrote:
> 
>> I believe this thread_local support is in XCode 8.2. From the link you
>> shared:
>> 
>>> Xcode 8.2 requires a Mac running macOS 10.11.5 or later
>> 
>> This means that users can upgrade the compiler on El Capitan just fine
>> without a system upgrade.
>> 
>> Users on Yosemite need to do a system upgrade to pick up the new compiler
>> however.
>> 
>> On Mon, Dec 19, 2016 at 12:33 PM, Joris Van Remoortere <
>> jo...@mesosphere.io>
>> wrote:
>> 
>>> Is my understanding incorrect regarding the ability to upgrade the
>> compiler
>>> version on Yosemite and El Capitan without requiring a full system
>> upgrade?
>>> 
>>> @Mpark are you making a case for not updating to `thread_local` just yet?
>>> 
>>> —
>>> *Joris Van Remoortere*
>>> Mesosphere
>>> 
>>> On Fri, Dec 16, 2016 at 11:11 AM, Michael Park  wrote:
>>> 
 Brief survey from the #dev channel: https://mesos.slack.com/
 archives/dev/p1481760285000430
 
 Yosemite 10.10: Fail. Compilation error. (by @hausdorff
 https://mesos.slack.com/archives/dev/p1481760552000435)
 El Capitan 10.11: Fail. Compilation error. (by @zhitao
 https://mesos.slack.com/files/zhitao/F3F7WUCNM/-.diff)
 Sierra 10.12: Success (by @mpark)
 
 On Wed, Dec 14, 2016 at 3:27 PM, Joris Van Remoortere <
>>> jo...@mesosphere.io
> 
 wrote:
 
> The time has come and we finally have `thread_local` support in the
>>> Apple
> tool chain:
> https://developer.apple.com/library/content/releasenotes/Dev
> 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`.
> https://github.com/apache/mesos/blob/812e5e3d4e4d9e044a1cfe6
> 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
> 
 
>>> 
>>> --
>>> Zameer Manji
>>> 
>> 

Re: thread_local supported on Apple

[Joris Van Remoortere]

Thanks for your input Zameer.

Is it common for developers on mac to use XCode as their compilation
environment as well? I would think if you used clang on the command line
then you could still install an updated version of clang without having to
do a system upgrade from Yosemite?

I'm getting the impression that it's reasonable to make this change without
a deprecation cycle. Please let me know if you (anyone) disagrees.

—
*Joris Van Remoortere*
Mesosphere

On Mon, Dec 19, 2016 at 2:17 PM, Zameer Manji  wrote:

> I believe this thread_local support is in XCode 8.2. From the link you
> shared:
>
> > Xcode 8.2 requires a Mac running macOS 10.11.5 or later
>
> This means that users can upgrade the compiler on El Capitan just fine
> without a system upgrade.
>
> Users on Yosemite need to do a system upgrade to pick up the new compiler
> however.
>
> On Mon, Dec 19, 2016 at 12:33 PM, Joris Van Remoortere <
> jo...@mesosphere.io>
> wrote:
>
> > Is my understanding incorrect regarding the ability to upgrade the
> compiler
> > version on Yosemite and El Capitan without requiring a full system
> upgrade?
> >
> > @Mpark are you making a case for not updating to `thread_local` just yet?
> >
> > —
> > *Joris Van Remoortere*
> > Mesosphere
> >
> > On Fri, Dec 16, 2016 at 11:11 AM, Michael Park  wrote:
> >
> > > Brief survey from the #dev channel: https://mesos.slack.com/
> > > archives/dev/p1481760285000430
> > >
> > > Yosemite 10.10: Fail. Compilation error. (by @hausdorff
> > > https://mesos.slack.com/archives/dev/p1481760552000435)
> > > El Capitan 10.11: Fail. Compilation error. (by @zhitao
> > > https://mesos.slack.com/files/zhitao/F3F7WUCNM/-.diff)
> > > Sierra 10.12: Success (by @mpark)
> > >
> > > On Wed, Dec 14, 2016 at 3:27 PM, Joris Van Remoortere <
> > jo...@mesosphere.io
> > > >
> > > wrote:
> > >
> > > > The time has come and we finally have `thread_local` support in the
> > Apple
> > > > tool chain:
> > > > https://developer.apple.com/library/content/releasenotes/Dev
> > > > 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`.
> > > > https://github.com/apache/mesos/blob/812e5e3d4e4d9e044a1cfe6
> > > > 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
> > > >
> > >
> >
> > --
> > Zameer Manji
> >
>

Re: thread_local supported on Apple

[Zameer Manji]

I believe this thread_local support is in XCode 8.2. From the link you
shared:

> Xcode 8.2 requires a Mac running macOS 10.11.5 or later

This means that users can upgrade the compiler on El Capitan just fine
without a system upgrade.

Users on Yosemite need to do a system upgrade to pick up the new compiler
however.

On Mon, Dec 19, 2016 at 12:33 PM, Joris Van Remoortere 
wrote:

> Is my understanding incorrect regarding the ability to upgrade the compiler
> version on Yosemite and El Capitan without requiring a full system upgrade?
>
> @Mpark are you making a case for not updating to `thread_local` just yet?
>
> —
> *Joris Van Remoortere*
> Mesosphere
>
> On Fri, Dec 16, 2016 at 11:11 AM, Michael Park  wrote:
>
> > Brief survey from the #dev channel: https://mesos.slack.com/
> > archives/dev/p1481760285000430
> >
> > Yosemite 10.10: Fail. Compilation error. (by @hausdorff
> > https://mesos.slack.com/archives/dev/p1481760552000435)
> > El Capitan 10.11: Fail. Compilation error. (by @zhitao
> > https://mesos.slack.com/files/zhitao/F3F7WUCNM/-.diff)
> > Sierra 10.12: Success (by @mpark)
> >
> > On Wed, Dec 14, 2016 at 3:27 PM, Joris Van Remoortere <
> jo...@mesosphere.io
> > >
> > wrote:
> >
> > > The time has come and we finally have `thread_local` support in the
> Apple
> > > tool chain:
> > > https://developer.apple.com/library/content/releasenotes/Dev
> > > 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`.
> > > https://github.com/apache/mesos/blob/812e5e3d4e4d9e044a1cfe6
> > > 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
> > >
> >
>
> --
> Zameer Manji
>

Re: thread_local supported on Apple

[Joris Van Remoortere]

Is my understanding incorrect regarding the ability to upgrade the compiler
version on Yosemite and El Capitan without requiring a full system upgrade?

@Mpark are you making a case for not updating to `thread_local` just yet?

—
*Joris Van Remoortere*
Mesosphere

On Fri, Dec 16, 2016 at 11:11 AM, Michael Park  wrote:

> Brief survey from the #dev channel: https://mesos.slack.com/
> archives/dev/p1481760285000430
>
> Yosemite 10.10: Fail. Compilation error. (by @hausdorff
> https://mesos.slack.com/archives/dev/p1481760552000435)
> El Capitan 10.11: Fail. Compilation error. (by @zhitao
> https://mesos.slack.com/files/zhitao/F3F7WUCNM/-.diff)
> Sierra 10.12: Success (by @mpark)
>
> On Wed, Dec 14, 2016 at 3:27 PM, Joris Van Remoortere  >
> wrote:
>
> > The time has come and we finally have `thread_local` support in the Apple
> > tool chain:
> > https://developer.apple.com/library/content/releasenotes/Dev
> > 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`.
> > https://github.com/apache/mesos/blob/812e5e3d4e4d9e044a1cfe6
> > 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
> >
>

Re: thread_local supported on Apple

[Michael Park]

Brief survey from the #dev channel: https://mesos.slack.com/
archives/dev/p1481760285000430

Yosemite 10.10: Fail. Compilation error. (by @hausdorff
https://mesos.slack.com/archives/dev/p1481760552000435)
El Capitan 10.11: Fail. Compilation error. (by @zhitao
https://mesos.slack.com/files/zhitao/F3F7WUCNM/-.diff)
Sierra 10.12: Success (by @mpark)

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

> The time has come and we finally have `thread_local` support in the Apple
> tool chain:
> https://developer.apple.com/library/content/releasenotes/Dev
> 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`.
> https://github.com/apache/mesos/blob/812e5e3d4e4d9e044a1cfe6
> 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
>

Re: thread_local supported on Apple

[tommy xiao]

+1

2016-12-15 7:27 GMT+08:00 Joris Van Remoortere :

> The time has come and we finally have `thread_local` support in the Apple
> tool chain:
> https://developer.apple.com/library/content/releasenotes/
> DeveloperTools/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`.
> https://github.com/apache/mesos/blob/812e5e3d4e4d9e044a1cfe6cc7eaab
> 10efb499b6/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
>



-- 
Deshi Xiao
Twitter: xds2000
E-mail: xiaods(AT)gmail.com