This is the mail archive of the
mailing list for the GCC project.
Re: [Mingw-w64-public] Fwd: [patch] Reimplement GNU threads library on native Windows
- From: Jacek Caban <jacek at codeweavers dot com>
- To: Liu Hao <lh_mouse at 126 dot com>, Eric Botcazou <ebotcazou at adacore dot com>
- Cc: libstdc++ at gcc dot gnu dot org, GCC Patches <gcc-patches at gcc dot gnu dot org>, mingw-w64-public at lists dot sourceforge dot net
- Date: Tue, 2 Jul 2019 12:15:41 +0200
- Subject: Re: [Mingw-w64-public] Fwd: [patch] Reimplement GNU threads library on native Windows
- References: <2175092.5hV0XgF4mA@polaris> <email@example.com> <firstname.lastname@example.org> <2395489.buBb56uQH1@polaris> <email@example.com> <firstname.lastname@example.org>
- Reply-to: mingw-w64-public at lists dot sourceforge dot net
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
imply resource ownership and are not unique identifiers); thread
This was considered but ultimately rejected, as you can do nothing
thread Id, i.e. you need a handle for everything. But the
`DWORD` or `unsigned long`) would be a better alternative.
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
I meant unique, not identical.