You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mesos.apache.org by Joris Van Remoortere <jo...@mesosphere.io> on 2016/12/14 23:27:29 UTC
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
Re: thread_local supported on Apple
Posted by Joris Van Remoortere <jo...@mesosphere.io>.
__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 <vi...@mesosphere.io> 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 <mp...@apache.org> 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 <jo...@gmail.com> wrote:
> >>
> >>
> >>> On Dec 19, 2016, at 3:00 PM, Joris Van Remoortere <joris@mesosphere.io
> >
> >> 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 <zm...@apache.org>
> 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 <
> >>>> joris@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 <mp...@apache.org>
> >> 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 <
> >>>>> joris@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
Posted by Vinod Kone <vi...@mesosphere.io>.
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 <mp...@apache.org> 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 <jo...@gmail.com> wrote:
>>
>>
>>> On Dec 19, 2016, at 3:00 PM, Joris Van Remoortere <jo...@mesosphere.io>
>> 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 <zm...@apache.org> 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 <
>>>> joris@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 <mp...@apache.org>
>> 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 <
>>>>> joris@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
Posted by Michael Park <mp...@apache.org>.
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 <jo...@gmail.com> wrote:
>
> > On Dec 19, 2016, at 3:00 PM, Joris Van Remoortere <jo...@mesosphere.io>
> 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 <zm...@apache.org> 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 <
> >> joris@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 <mp...@apache.org>
> 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 <
> >>> joris@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
Posted by James Peach <jo...@gmail.com>.
> On Dec 19, 2016, at 3:00 PM, Joris Van Remoortere <jo...@mesosphere.io> 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 <zm...@apache.org> 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 <
>> joris@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 <mp...@apache.org> 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 <
>>> joris@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
Posted by Joris Van Remoortere <jo...@mesosphere.io>.
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 <zm...@apache.org> 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 <
> joris@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 <mp...@apache.org> 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 <
> > joris@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
Posted by Zameer Manji <zm...@apache.org>.
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 <mp...@apache.org> 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 <
> joris@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
Posted by Joris Van Remoortere <jo...@mesosphere.io>.
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 <mp...@apache.org> 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 <joris@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
> >
>
Re: thread_local supported on Apple
Posted by Michael Park <mp...@apache.org>.
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
>
Re: thread_local supported on Apple
Posted by tommy xiao <xi...@gmail.com>.
+1
2016-12-15 7:27 GMT+08:00 Joris Van Remoortere <jo...@mesosphere.io>:
> 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