[Mesa-dev] [PATCH 1/2] c11/threads: implement thrd_current on Windows

Jose Fonseca jfonseca at vmware.com
Mon Apr 24 16:03:52 UTC 2017


On 24/04/17 16:46, Emil Velikov wrote:
> On 24 April 2017 at 12:56, Jose Fonseca <jfonseca at vmware.com> wrote:
>> On 24/04/17 12:26, Emil Velikov wrote:
>>>
>>> On 21 April 2017 at 16:45, Jose Fonseca <jfonseca at vmware.com> wrote:
>>>>
>>>> I reread http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf and is
>>>> not explicit.
>>>>
>>>> But I checked C11 threads.h implementation and thrd_current also uses
>>>> DuplicateHandle.
>>>>
>>>> So C11/threads_win32.h is correct.  And ISO C11 standard commited screwed
>>>> up
>>>> here.  Maybe they'll introduce thread ids  at some point (MSVC's
>>>> implementation has a non-standard _Thrd_id() function), and we can use
>>>> it,
>>>> but until then, it's better not pretend that thrd_current meets our needs
>>>> because it doesn't.
>>>>
>>> Right, thanks for the clarification Jose!
>>>
>>> Personally I won't go as far as "ISO C11 standard commited screwed up
>>> here", since they are not the ones that wrote the threads
>>> implementation in Windows.
>>
>>>
>>> Perhaps MS can address that if they see enough value in it, but even
>>> then there's the older/released versions of Windows to think about.
>>
>> No my point is that it's *impossible* for Microsoft, us, or anybody to do a
>> C11 threads where thrd_current is light weight on Windows.  Period.  So that
>> shows a lack of foresight from the committee.
>>
> I thought you only meant *impossible to implement based on the public
> API available". Although it seems that you have enough knowledge about
> Windows internals to come to this conclusion.

Yes, I only meant based on the publicly available APIs.

But I see what you mean now: indeed if Microsoft changed the Win32 
thread API nothing is impossible.

But then again, isn't it a failure to design a C thread abstraction that 
would require changes to a major OS to be implemented efficiently?  Even 
if Microsoft  updated the Win32 API, that would never work for 
previously released Windows versions.

Please note that MSVC CRT only uses public Win32 APIs.  It doesn't use 
hiddden stuff as far as I know.   After all, the CRT source comes with 
MSVC.  So all Win32 APIs it uses end up becoming public knowledge / 
documented.

>
>> Or perhaps the committee decided that a light weight thrd_current was
>> unimportant.  But in that case I think it was a mistake.
>>
>> Anyway, I'm sure there might have been other tradeoffs and issues that lead
>> the committe to come to this, or merely lack of time, or they willingly
>> decided to get feet wet before dived in.  All I mean is that at least for
>> our use case, the current C threads.h design does not fit our needs, at
>> least on Windows.
>>
> Agreed.
>
> In case it's not obvious - I was/am looking at the GLX_USE_TLS vs
> other codepaths in mapi.
> We might be able to nuke the non GLX_USE_TLS [which uses the above
> code] while preserving Windows support.
> Might ask you/Brian to test some branches as i have something serious.

Sure.

Jose



More information about the mesa-dev mailing list