C++ exceptions: pthread key allocation error for __gthread_key_create

Sebastian Huber sebastian.huber at embedded-brains.de
Wed Dec 7 06:18:51 UTC 2016



On 06/12/16 23:07, Chris Johns wrote:
> On 06/12/2016 18:02, Sebastian Huber wrote:
>> On 06/12/16 01:25, Chris Johns wrote:
>>> On 05/12/2016 18:19, Sebastian Huber wrote:
>>>> On 05/12/16 07:57, Chris Johns wrote:
>>>>> Is it the user who needs to account for the gthread key if using C++?
>>>>
>>>> Yes, its up to the user to ensure that there are enough POSIX keys
>>>> available. This is quite a pain.
>>>
>>> It is also error prone and silent and this is a real concern because
>>> it exposed very real issues if not correctly configured. The libstdc++
>>> is fragile in this regard.
>>>
>>>>
>>>> Why is no TLS value used (instead of the POSIX key)?
>>>>
>>>
>>> I do not know. It is wrapped by our gthread wrapper.
>>
>> It seems libstdc++ still uses POSIX keys in case it needs a destructor.
>>
>
> If the architecture has _GLIBCXX_HAVE_TLS defined it can use TLS.

Yes, but it seems not for thread-local storage that needs a destructor.

>
>>>
>>>> It would be possible to make the pthread_key_t self-contained, 
>>>> however,
>>>> for the thread-specific value you need some system provided storage
>>>> (currently the workspace).
>>>
>>> I do not know what this means.
>>
>> The problem is that all storage for POSIX keys is currently system
>> provided. Since it uses the workspace, the configuration must account
>> for libstdc++ resources.
>>
>> If we could change it to use only user provided storage, then we
>> wouldn't have to deal with the configuration.
>>
>
> Would we have to change all POSIX calls? Adding support for just keys 
> means this is fixed but other calls can still fail and some of these 
> are not handled by libstdc++ like this call.

I assumed you use the RTEMS thread model. It uses self-contained objects 
for the mutexes and condition variables. Only the threads use the POSIX 
API and if creation goes wrong a system error exception is thrown.

>
> It is an error for libstdc++ to ignore the error or assume a behaviour 
> based on the call failing.

Yes, however, its good to avoid potential error cases in general so that 
there is no need to deal with an error.

-- 
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax     : +49 89 189 47 41-09
E-Mail  : sebastian.huber at embedded-brains.de
PGP     : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.



More information about the devel mailing list