> On July 27, 2015, 5:54 p.m., Joseph Wu wrote: > > 3rdparty/libprocess/3rdparty/stout/include/stout/thread_local.hpp, line 25 > > <https://reviews.apache.org/r/36845/diff/1/?file=1022249#file1022249line25> > > > > `TLS` might be a bit too short for readable code. (And people that > > google it will come up with Transport Layer Security, instead of Thread > > Local Storage.) > > Maybe `THREAD_LOCAL` would be better.
I like THREAD_LOCAL too, it approximates 'thread_local' pretty well. ;-) - Benjamin ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/36845/#review93142 ----------------------------------------------------------- On July 27, 2015, 7:59 a.m., Joris Van Remoortere wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/36845/ > ----------------------------------------------------------- > > (Updated July 27, 2015, 7:59 a.m.) > > > Review request for mesos, Benjamin Hindman, Artem Harutyunyan, and Michael > Park. > > > Bugs: MESOS-3119 > https://issues.apache.org/jira/browse/MESOS-3119 > > > Repository: mesos > > > Description > ------- > > This replaced the ThreadLocal primitive with the new c++11 standard. > The exception is on OSX where we use `__thread` as thread_local is not > supported. > > > Diffs > ----- > > 3rdparty/libprocess/3rdparty/stout/Makefile.am > 89e7b1854bd7f449f4f0027d76c6430d259a24de > 3rdparty/libprocess/3rdparty/stout/include/Makefile.am > 5c19e3ef8ba50ab007eda26b752441f076ca7ed0 > 3rdparty/libprocess/3rdparty/stout/include/stout/thread.hpp > 552d6e97c882a36d6a889af205c422e51f544b34 > 3rdparty/libprocess/3rdparty/stout/include/stout/thread_local.hpp > PRE-CREATION > 3rdparty/libprocess/3rdparty/stout/tests/thread_tests.cpp > 319fcdf517b24f5bb9c85dad4093b09ec87e915e > > Diff: https://reviews.apache.org/r/36845/diff/ > > > Testing > ------- > > dependens on follow-up patch. > > > Thanks, > > Joris Van Remoortere > >
