On 7/6/2026 4:13 PM, Heikki Linnakangas wrote: > On 07/07/2026 00:01, [email protected] wrote: >> On 7/6/26 3:48 PM, Heikki Linnakangas <[email protected]> wrote: >>> On 06/07/2026 15:09, Thomas Munro wrote: >>>> +#ifdef WIN32 >>>> + >>>> + /* >>>> + * Retrieve handle passed here by pg_thrd_create() before >>>> allowing this >>>> + * thread to run. (pg_thrd_current() can't use CurrentThread(), >>>> because >>>> + * that returns a pseudo-handle with the same value in all >>>> threads.) >>>> + */ >>>> + Assert(start_info->self); >>>> + my_thrd_handle = start_info->self; >>>> +#endif >>> >>> Does that refer to the GetCurrentThreadId() function? We use that in a >>> few places currently. >>> >>> How can it return the same value in all threads, isn't that completely >>> useless? And does that mean all our current uses of it are broken? >> >> GetCurrentThread() not GetCurrentThreadId()... GetCurrentThread() >> returns a special sentinel handle (-2) that when passed to another >> Win32 function causes the kernel to resolve to whatever thread made >> the call.... >> >> So, no-- not broken. > > Ah gotcha. Could we use GetCurrentThreadId() here then? (I have no > problem with the way it's currently done in the patch either though, > just curious) > > - Heikki > I haven't looked at all of the code, but I would assume there is a WaitFor...Object() somewhere and those only work with actual handles...not id's. GetCurrentThreadId() returns a dword for id. I'll look over the patches as well.
-- Bryan Green EDB: https://www.enterprisedb.com
