Re: thread_local supported on Apple
__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`. > >>> https://github.com/apache/mesos/blob/812e5e3d4e4d9e044a1cfe6 > >>> cc7eaab10efb499b6/3rdparty/stout/include/stout/thread_local.hpp > >>>
Re: thread_local supported on Apple
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
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
> 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
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
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
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
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
+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
thread_local supported on Apple
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/812e5e3d4e4d9e044a1cfe6cc7eaab10efb499b6/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