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...
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? -- "What Huxley teaches is that in the age of advanced technology, spiritual devastation is more likely to come from an enemy with a smiling face than from one whose countenance exudes suspicion and hate." Neil Postman