Re: [boost] [err] RFC

Subject: Re: [boost] [err] RFC
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2016-01-11 16:51:43

Le 11/01/2016 22:13, Domagoj Saric a écrit :
> On 10.1.2016. 0:45, Vicente J. Botet Escriba wrote:
> > Le 10/01/2016 00:02, Domagoj Saric a écrit :
> >>
> >> ps. OT/'to whom it may concern': fixing the 'too strong assertions'
> >> problem (allowing multiple fallible_results to exist) and making it
> >> work on Android (where we still don't have even proper 'POD thread
> >> locals') with Clang forced me to reinvent boost::thread_specific_ptr
> >> (to avoid a dependency on Boost.Thread) in the process of which I
> >> found that Boost.Thread only asserts/'verifies' that calls to
> >> pthread_key_create() and pthread_setspecific() succeeded (which my
> >> fail with ENOMEM)...
> >>
> >>
> > Hi,
> >
> > Please, create a Trac ticket so we don't forget it (or a github 
> issue if
> > you prefer).
>
> https://svn.boost.org/trac/boost/ticket/11903
> unfortunately I forgot to login before submitting so it's anonymous...
>
Thanks and no problem.
> > Ah, if you have a patch it will be welcome also :)
>
> No, as I don't use Boost.Thread...'we are now getting deeper into OT 
> but': if you fix this 'conventonally' by throwing exceptions that will 
> make the TLS helper functions no longer nothrow which brings me to a 
> related dillema I had with the C++11 thread_local keyword.
> Checking the latest draft of the standard I could not figure out what 
> are the guarantees, if any, about thread_local WRT to (its) 
> resource/storage allocation/construction. AFAIK, with proper support 
> from the loader and the OS, it is possible to implement C++11 TLS 
> (including function thread_local statics) so that thread_local storage 
> is allocated on thread creation meaning that if the thread succesfully 
> starts all thread_local storage is already preallocated...And, as I 
> said, I could not figure out whether the standard assumes this or not, 
> and if not, how is storage allocation failure reported...with 
> std::bad_alloc? and is a try-catch around a function local static 
> thread_local enough to catch it?
>
>
The best will be to ask in std-discussion :)
I would say that thread_local don't need any allocation (I would store 
them on the stack).

Vicente