On 24 April 2017 at 12:56, Jose Fonseca <[email protected]> wrote: > On 24/04/17 12:26, Emil Velikov wrote: >> >> On 21 April 2017 at 16:45, Jose Fonseca <[email protected]> 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 _______________________________________________ mesa-dev mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/mesa-dev
