C++ exceptions: pthread key allocation error for __gthread_key_create

Chris Johns chrisj at rtems.org
Tue Dec 6 22:07:25 UTC 2016


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.

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

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

Chris


More information about the devel mailing list