C++ exceptions: pthread key allocation error for __gthread_key_create
Chris Johns
chrisj at rtems.org
Wed Dec 7 06:29:47 UTC 2016
On 07/12/2016 17:18, Sebastian Huber wrote:
> 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:
>>>>> 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.
Yes.
> 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.
What sort of exception?
Remember the key in question is related to exception processing. A
terminate or related call may be ok to make but raising an exception
should be avoided.
>> 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.
Yes I am not against the approach and actually welcome it. The point is
the code is written for the most popular pthread design and not the
actual standard. In the overall context it is a small point but it is
still important to make.
Chris
More information about the devel
mailing list