[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