Title
Obtaining native handle of the current thread
Status
nad
Section
[thread.req.native] [thread.thread.this]
Submitter
Matt Austern

Created on 2014-03-31.00:00:00 last changed 111 months ago

Messages

Date: 2015-05-08.04:23:26

Proposed resolution:

This wording is relative to N3936.

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

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

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

    namespace std {
      […]
      namespace this_thread {
        thread::id get_id() noexcept;
        thread::native_handle_type native_handle();
        […]
      }
    }
    
  3. In [thread.thread.this] add:

    namespace std {
      namespace this_thread {
        thread::id get_id() noexcept;
        thread::native_handle_type native_handle(); // See [thread.req.native]
        […]
      }
    }
    
Date: 2015-05-08.04:23:26

[ 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.

Date: 2015-04-04.16:45:17

[ 2015-02 Cologne ]

Handed over to SG1.

Date: 2014-03-31.00:00:00

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 [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 [thread.thread.member].

History
Date User Action Args
2015-10-21 05:22:23adminsetstatus: open -> nad
2015-05-08 04:23:26adminsetmessages: + msg7399
2015-04-04 16:45:17adminsetmessages: + msg7335
2015-04-04 16:45:17adminsetstatus: new -> open
2014-04-03 19:37:18adminsetmessages: + msg6937
2014-03-31 00:00:00admincreate