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

[Emil Velikov]

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.

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

>> That aside - can we reword the comment to something like the following:
>>
>>
>>    /* GetCurrentThread() returns a pseudo-handle, which we need
>>     * to pass to DuplicateHandle. Only the resulting handle can be used
>>     * from other threads.
>>     *
>>     * Note that neither handle can be compared to the one by
>> thread_create.
>>     * Only the thread IDs - as returned by GetThreadId and
>> GetCurrentThreadId
>>     * can be compared directly.
>>     *
>>     * Other potential solutions would be:
>>     * - define thrd_t as a thread Ids, but this would mean we'd need
>> to OpenThread for many operations
>>     * - use malloc'ed memory for thrd_t. This would imply using TLS
>> for current thread.
>>     *
>>     * Neither is particularly nice.
>>     */
>>
>>
>> Thanks
>> Emil
>>
>
> Looks good.
>
> Though the existing
>
>    "Life would be much easier if C11 threads had different abstractions for
>    threads and thread IDs, just like C++11 threads does..."
>
> paragraph could stay.  I'm still hoping that one day C standard has distinct
> types for threads and thread ids is, as the only way for this to be resolved
> to everybody's satisfaction.
>
Sure thing.

Thanks again!
Emil