[Mesa-dev] [PATCH 1/6] c11: add c11 compatibility wrapper around stdlib.h

Jose Fonseca jfonseca at vmware.com
Thu Mar 12 03:11:17 PDT 2015


On 12/03/15 00:07, Emil Velikov wrote:
> On 9 March 2015 at 11:54, Jose Fonseca <jfonseca at vmware.com> wrote:
>> On 07/03/15 19:38, Emil Velikov wrote:
>>>
>>> On 07/03/15 07:23, Jose Fonseca wrote:
>>> ...
>>>>
>>>> we still
>>>> didn't eliminate the use of non-portable _MTX_INITIALIZER_NP from Mesa
>>>> tree gave me pause.
>>>>
>>> The only way I can think about resolving this, is to use call_once() to
>>> initialize the mutex,
>>
>>
>> Yes, I'm afraid so.
>>
> Which makes me wonder, why does no other place in mesa (be that glx,
> gallium etc.) do so already ?

I believe mostly for convenience, as I said.

I was the one who introduced c11 threads emulation headers, and 
replacing the non-portable static initialization with call_once would be 
a lot of work which I wasn't ready to take on at that time, hence I 
introduced _MTX_INITIALIZER_NP to facilite the transition.

I was also hopeful another revision of ISO C would introduce static 
initializer in threads.  But nowadays I suspect it might be not.

> Also it seem that some places might have to stick to pthreads. Haven't
> checked the details though.
>
> * src/glx/apple
> pthread_threadid_np
> pthread_is_threaded_np
>
>
> * src/gallium/auxiliary/os
> pthread_sigmask
> pthread_setname_np

Yeah, I think it's unavoidable.  I think that it's fair to assume that 
when C11 threads are implemented by the system, they can interoperate 
with pthreads, even though the c11 threads types are not mere typedefs 
of pthread types.

If worst come true, we can always stick with our custom c11_threads.h 
implementation.


>
> * src/gallium/state_trackers/omx/
> pthread_join ? missing a matching thread_create



Jose



More information about the mesa-dev mailing list