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

[Jonathan Wakely via Phabricator via libcxx-commits]

jwakely added a comment.

This reminds me of an often-requested extension to `std::fstream` to allow it to take ownership of a `FILE*` or unix file descriptor. In libstdc++ we do support that, but only by using a non-standard filebuf type, `__gnu_cxx::stdio_filebuf`. It's not available for `std::basic_filebuf`. Doing that would be an alternative design for this (that is, a non-standard `native_thread` type that you'd use instead of `std::thread`). That wouldn't be interchangeable with `std::thread` though, so I can see why you want to extend the existing type.

I was going to mention that p2019 suggests a very different approach for platform-specific properties of the new thread, but I see you already covered that.

I agree with Olivier that this would have to be conditionally supported, but that's already implied by the use of `native_handle_type` (which isn't required to exist). For libstdc++, we don't currently do anything special that's specific to C++ when creating a new thread, so we could support this exactly the same way.

However, I'm concerned that this changes the result of things like `is_constructible<thread, int>` or `is_constructible<thread, void*>`. On GNU/Linux `thread::native_handle_type` is just `unsigned long`, on MinGW-w64 it's `uintptr_t`, so this would mean you can construct a `std::thread` with any integer. On other targets it's a `void*`. I'd be happier if the new constructor required a tag type to say "I know what I'm doing", e.g. `thread(from_native_t, native_handle_type)` so you'd say `std::thread t(std::from_native, thr);`. Or JF's suggestion of a static member function would also work: `auto t = std::thread::from_native(thr);`

For `jthread` constructing from a native handle isn't going to allow you to stop the thread, meaning it will hang in the destructor (or move assignment op). So there seems no point adding the same constructor to `jthread`. But you could allow construction from a native handle **and** a `stop_source` (with a precondition that `stop_possible()` is true). People could still shoot themselves in the foot by passing a stop source that is unconnected to the thread the handle refers to, but at least there's a possibility to get it right.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D91992