[libcxx-commits] [PATCH] D91992: [libc++] Add an extension to allow constructing std::thread from native handles

[Olivier Giroux via Phabricator via libcxx-commits]

__simt__ added a comment.

I'm not sold on this but I'm not deeply opposed either.

It's entirely possible for the C++ library to add code around the thread launch to ensure some invariants it has (X state is initialized, Y mode is enabled/disabled, Z mechanism is armed to track this thread exists/exits) and will not be ensured by going to a lower layer and just creating a thread there directly. That could be true even when the C++ library itself does that, and could give you the native handle that results from itself doing it.

Role-playing SG1 for a bit, I think if SG1 took on this extension it would either be optional/implementation-defined or it would have permission to throw if it can't adopt the thread (and on some platforms, potentially it would _always_ throw). That might result in some other ancillary design elements, like a constexpr way to query if adoption is supported at all and/or a way for the native launch to invoke the code that thread uses to ensure its invariants.

Also, applying this treatment to jthread is a bit less elegant again, which is annoying, but not impossible.

Ok, backing up: should libcxx have this extension?

As I said, I'm not opposed to it but a little while ago I was told that libcxx doesn't do extensions in the mainline. I don't remember what it was I had in mind, maybe it was atomic<>::wait() support for timeouts. At the time, the answer was to do this in a deployment fork, not mainline.

Do we want to do nice extensions? And if so, what's the basic litmus test for knowing we should do it?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D91992/new/

https://reviews.llvm.org/D91992