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.


Jacek



_______________________________________________
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Reply via email to