On 02.07.2019 14:58, Jacek Caban wrote: > On 7/2/19 1:35 PM, LRN wrote: >> On 02.07.2019 13:42, Jacek Caban wrote: >>> On 02/07/2019 12:38, LRN wrote: >>>> On 02.07.2019 13:15, Jacek Caban wrote: >>>>> On 02/07/2019 12:12, Jacek Caban wrote: >>>>>> On 02/07/2019 11:57, Liu Hao wrote: >>>>>> >>>>>>> 在 2019/7/2 下午5:19, Eric Botcazou 写道: >>>>>>>>> It seems inappropriate to use handles as thread identifiers (as >>>>>>>>> handles >>>>>>>>> imply resource ownership and are not unique identifiers); thread >>>>>>>>> IDs (as >>>>>>>>> `DWORD` or `unsigned long`) would be a better alternative. >>>>>>>> This was considered but ultimately rejected, as you can do nothing >>>>>>>> with a >>>>>>>> thread Id, i.e. you need a handle for everything. But the >>>>>>>> __gthread_equal >>>>>>>> routine does compare the Ids and not the handles. >>>>>>>> >>>>>>> The `OpenThread()` function can obtain a handle by thread ID. It returns >>>>>>> a real handle that has to be closed when it is out of use. Using the >>>>>>> pseudo handle returned by `GetCurrentThread()` may be more efficient if >>>>>>> the target thread ID is equal to `GetCurrentThreadId()`. >>>>>> The problem with thread id is that it's not valid nor guaranteed to be >>>>>> identical after the thread is terminated. A handle needs to be used >>>>>> for that. >>>>> I meant unique, not identical. >>>>> >>>> According to linux.die.net[0], Linux kernel re-uses thread IDs. This >>>> stackoverflow answer[1] claims that this applies to all POSIX threads >>>> implementations, citing opengroup spec[2]. >>> >>> It will not reuse them until you detach or join the thread. Joining may >>> happen after the thread is terminated. >>> >> It just means that you may not be able to use Windows thread IDs for that, >> but >> using your own, homegrown thread IDs would be OK (just make sure an ID is >> valid >> until a thread is joined or detached - that would usually imply keeping >> metadata of a thread around after it's terminated). > > > That would be additional complication with additional problems. Without > a handle, there is no reliable way to detect if thread is terminated and > if it's not, you need to wait in join. Also, you'd replace handle leak > to internal data leak. > >
So what you want is for the thread library to keep thread metadata around while the thread exists, then destroy that metadata when the thread terminates (preventing leaks), and still be able to respond to thread-API calls (such as join()) made from other threads toward this (now terminated) thread? I don't know W32 and POSIX thread APIs to judge whether this is actually doable that way, regardless of whether thread IDs are handles or not.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
