Boost logo

Boost :

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


Boost list run by bdawes at, gregod at, cpdaniel at, john at