Date: Mon, 19 Aug 2019 10:37:42 -0400
> On Aug 19, 2019, at 10:10 AM, Niall Douglas via Liaison <liaison_at_[hidden]> wrote:
>
>> On 19/08/2019 14:54, pete_at_[hidden] wrote:
>> Can you be more specific about what is being proposed?
>
> LEWG-I has forwarded P1759R1 to LEWG to begin standardisation. It
> hard-assumes a one-one relation between "native_handle_type" and some
> single implementation handle type.
>
> I strenuously disagree with that design choice. One might be able to get
> away with it on POSIX most of the time, but the world is not POSIX.
>
> In the real world, there are many kinds of native handle type. That's
> why it needs union storage in my opinion, and a discriminant to tell you
> which is in play right now.
>
> That's my proposal.
>
>> In C++11, native_handle_type reserved a name with no portable semantics. The requirement is that it can be passed to various implementation-defined functions to do various implementation-defined things. I pointed out at the time that there was no single Windows type that supported all of the operations of std::thread on all the variants of Windows (in particular, WinCE had some quirks), so there was no obvious candidate for native_handle_type on Windows. The Dinkumware implementation (which I wrote) puts all the threading stuff on top of a portable layer (now more-or-less standardized in C), and native_handle_type is the corresponding type from that layer, i.e., not a native Windows type.
>
> You make an excellent point that one of the union options ought to be
> pthread_t.
That's not my point at all.
As it currently stands, native_handle_type has no mandatory semantics. That means that the implementation does whatever is necessary to make it work, for some unspecified meaning of "work".
There's nothing in the standard that prevents an implementation from using a union, but that doesn't address the Windows issue. Under Windows you need (needed?) two different things, depending on what function you're calling. That's not a union; it's a struct with two elements.
I don't see where requiring a discriminated union is better than allowing implementations to do what they need.
>
> Be aware that nobody is proposing that std::thread::native_handle_type
> be immediately changed. This would break ABI. However it may become
> changed if a toolchain breaks ABI.
Changed to what? That's why I asked: I don't know what the goal here is. If the intention is to provide portable semantics for native_handle_type, I think that's a mistake. We already have std::thread, std::mutex, etc. for portable code. The non-portable stuff, which is entirely implementation-defined, is done with native_handle_type.
-- Pete
Roundhouse Consulting, Ltd.
>
>> On 19/08/2019 14:54, pete_at_[hidden] wrote:
>> Can you be more specific about what is being proposed?
>
> LEWG-I has forwarded P1759R1 to LEWG to begin standardisation. It
> hard-assumes a one-one relation between "native_handle_type" and some
> single implementation handle type.
>
> I strenuously disagree with that design choice. One might be able to get
> away with it on POSIX most of the time, but the world is not POSIX.
>
> In the real world, there are many kinds of native handle type. That's
> why it needs union storage in my opinion, and a discriminant to tell you
> which is in play right now.
>
> That's my proposal.
>
>> In C++11, native_handle_type reserved a name with no portable semantics. The requirement is that it can be passed to various implementation-defined functions to do various implementation-defined things. I pointed out at the time that there was no single Windows type that supported all of the operations of std::thread on all the variants of Windows (in particular, WinCE had some quirks), so there was no obvious candidate for native_handle_type on Windows. The Dinkumware implementation (which I wrote) puts all the threading stuff on top of a portable layer (now more-or-less standardized in C), and native_handle_type is the corresponding type from that layer, i.e., not a native Windows type.
>
> You make an excellent point that one of the union options ought to be
> pthread_t.
That's not my point at all.
As it currently stands, native_handle_type has no mandatory semantics. That means that the implementation does whatever is necessary to make it work, for some unspecified meaning of "work".
There's nothing in the standard that prevents an implementation from using a union, but that doesn't address the Windows issue. Under Windows you need (needed?) two different things, depending on what function you're calling. That's not a union; it's a struct with two elements.
I don't see where requiring a discriminated union is better than allowing implementations to do what they need.
>
> Be aware that nobody is proposing that std::thread::native_handle_type
> be immediately changed. This would break ABI. However it may become
> changed if a toolchain breaks ABI.
Changed to what? That's why I asked: I don't know what the goal here is. If the intention is to provide portable semantics for native_handle_type, I think that's a mistake. We already have std::thread, std::mutex, etc. for portable code. The non-portable stuff, which is entirely implementation-defined, is done with native_handle_type.
-- Pete
Roundhouse Consulting, Ltd.
Received on 2019-08-19 09:40:00