> 0) complexifies comparison of thread IDs without obvious benefits, and
The reverse argument is also true: using IDs would complexify everything else
with the only benefit of simplifying the equal primitive.
> 1) does not work reliably because handles can be duplicated, and
That's pure FUD.
>
在 2019/7/29 22:43, JonY 写道:
>
> Any updates?
>
No. I am still under the impression that using thread handles as
`std::thread::id`s:
0) complexifies comparison of thread IDs without obvious benefits, and
1) does not work reliably because handles can be duplicated, and
2) makes `__gthread_self()`
On 7/3/19 12:55 PM, Liu Hao wrote:
> 在 2019/7/2 下午8:27, Jonathan Wakely 写道:
>>
>> What do you mean by "unclosed thread"? If I read it correctly, the MSDN
>> page
>> refers to closing a handle (which makes sense), not closing a thread.
>>
>
> Yes, it meant a thread which has terminated but not dele
在 2019/7/2 下午8:27, Jonathan Wakely 写道:
>
> What do you mean by "unclosed thread"? If I read it correctly, the MSDN
> page
> refers to closing a handle (which makes sense), not closing a thread.
>
Yes, it meant a thread which has terminated but not deleted due to some
handles left open.
>> This
On 02/07/19 20:14 +0800, Liu Hao wrote:
在 2019/7/2 下午8:00, Jonathan Wakely 写道:
The C++ standard says:
"The library may reuse the value of a thread::id of a terminated
thread that can no longer be joined."
So that's not a reason to use a handle.
According to MSDN [1] a thread ID is valid 'unt
在 2019/7/2 下午8:00, Jonathan Wakely 写道:
> The C++ standard says:
>
> "The library may reuse the value of a thread::id of a terminated
> thread that can no longer be joined."
>
> So that's not a reason to use a handle.
According to MSDN [1] a thread ID is valid 'until the thread has been
terminate
On 02/07/19 12:56 +0100, Jonathan Wakely wrote:
On 02/07/19 11:54 +0200, Eric Botcazou wrote:
Yes there are definitely still references to C++0x elsewhere in
libstdc++, especially in the testsuite, but let's not add new ones.
It's libgcc though, not libstdc++. And it's a bit inconvenient to h
On 02/07/19 12:15 +0200, 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);
thre
On 02/07/19 11:54 +0200, Eric Botcazou wrote:
Yes there are definitely still references to C++0x elsewhere in
libstdc++, especially in the testsuite, but let's not add new ones.
It's libgcc though, not libstdc++. And it's a bit inconvenient to have c++0x
on the one hand (gthr.h) and c++11 on t
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`) woul
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 consider
在 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,
> Yes there are definitely still references to C++0x elsewhere in
> libstdc++, especially in the testsuite, but let's not add new ones.
It's libgcc though, not libstdc++. And it's a bit inconvenient to have c++0x
on the one hand (gthr.h) and c++11 on the other hand (gthr-win32-thread.c); in
oth
On 02/07/19 11:23 +0200, Eric Botcazou wrote:
s/c++0x/c++11/ please, it hasn't been 0x for eight years now :-)
I suppose I didn't invent it though, so you'll probably find more with grep...
Yes there are definitely still references to C++0x elsewhere in
libstdc++, especially in the testsuite,
> s/c++0x/c++11/ please, it hasn't been 0x for eight years now :-)
I suppose I didn't invent it though, so you'll probably find more with grep...
--
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.
On 28/06/19 12:46 +0200, Eric Botcazou wrote:
+/* The implementation strategy for the c++0x thread support is as follows.
s/c++0x/c++11/ please, it hasn't been 0x for eight years now :-)
I haven't reviewed the rest yet, that just jumped out at me during a
quick skim of the patch.
在 2019/6/29 上午12:10, Jacek Caban 写道:
>
> You don't really need to store the whole __gthr_win32_thr_desc in TLS.
> If you stored just the handle, this wouldn't need a destructor.
>
>
The handle to be stored in the TLS ('the Handle' for short hereinafter)
should be a real handle, so there are a f
!
-- Forwarded message -
From: Eric Botcazou
Date: Fri, Jun 28, 2019 at 6:51 AM
Subject: [patch] Reimplement GNU threads library on native Windows
To:
Cc:
Hi,
this reimplements the GNU threads library on native Windows (except for the
Objective-C specific subset) using direct Win32 API calls, in
Hi,
this reimplements the GNU threads library on native Windows (except for the
Objective-C specific subset) using direct Win32 API calls, in lieu of the
implementation based on semaphores. This base implementations requires
Windows XP/Server 2003, which is the default minimal setting of MinGW
20 matches
Mail list logo
