This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of NAD status.

### 2379. Obtaining native handle of the current thread

Section: 33.2.3 [thread.req.native], 33.4.5 [thread.thread.this] Status: NAD Submitter: Matt Austern Opened: 2014-03-31 Last modified: 2015-10-21

Priority: Not Prioritized

View all issues with NAD status.

Discussion:

Class `thread` contains an implementation-defined type `thread::native_handle_type`, and an implementation-defined function `thread::native_handle()` that returns a value of that type. The presence and semantics of those members is implementation-defined; the intention is that they can be used for interoperability with libraries that rely on operating system specific features. (Posix libraries that accept arguments of type `pthread_t`, for example.)

Unfortunately, there appears to be no native handle support for the equivalent of `pthread_self()`. We can use `this_thread::get_id()` to obtain the `thread::id` of the current thread, but there is no mechanism for converting a `thread::id` to a `thread::native_handle`.

Proposed wording:

In 33.4.5 [thread.thread.this] add:

>     thread::native_handle_type native_handle(); // See 30.2.3

to the `this_thread` namespace synopsis.

Rationale:

Informally, we could address this issue either by adding a new function in `this_thread` or by providing a mechanism for converting between `thread::id` and `thread::native_handle`. I propose the former because it seems more localized, and doesn't involve saying anything more about implementation defined native functionality than we currently do.

It's intentional that the proposed resolution adds a declaration of `native_handle()` without adding a paragraph explaining what it does. This is because everything about `native_handle()` is implementation-defined. The standard does the same thing in 33.4.3.6 [thread.thread.member].

[2015-02 Cologne]

Handed over to SG1.

[2015-05 Lenexa, SG1 response]

Strong "don't care" reaction from SG1, after pointing out that this only matters in non-portable code, which can call pthread_self() or the like anyway, but the change also doesn't add any non-trivial implementation requirements. This defused initial strong opinions on both sides. Since this is essentially a feature request, we did not have sufficient consensus to proceed at this point. There was a feeling we should reconsider after making more sense out of the much more general TLS issues we have been discussing.

Proposed resolution:

This wording is relative to N3936.

1. Change 33.2.3 [thread.req.native] p1 as indicated:

   > -1- Several classes described in this Clause have members This Clause includes several members named `native_handle_type` and `native_handle`. The presence of these members and their semantics is implementation-defined. […]

2. In 33.4 [thread.threads], header `<thread>` synopsis, add:

   >     namespace std {
   >       […]
   >       namespace this_thread {
   >         thread::id get_id() noexcept;
   >         thread::native_handle_type native_handle();
   >         […]
   >       }
   >     }

3. In 33.4.5 [thread.thread.this] add:

   >     namespace std {
   >       namespace this_thread {
   >         thread::id get_id() noexcept;
   >         thread::native_handle_type native_handle(); // See 33.2.3 [thread.req.native]
   >         […]
   >       }
   >     }