-
Notifications
You must be signed in to change notification settings - Fork 1.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Expose a public unsafe API to spawn threads with unrestricted lifetime bounds #2546
Comments
I'm not sure I understand the motivation for this: why wouldn't callers just unsafely cast |
I think something like crossbeam's scoped threads is a better solution. |
What you can do is put a
Scoped thread implementations like crossbeam's are exactly what could be made simpler (and possibly slightly safer and more efficient), if there was an API for spawning lifetime unrestricted threads.
Since you can't use the |
Closing in favor of rust-lang/rust#55043. |
Currently, the only way to spawn a thread is with
'static
lifetime bounds on the closure and its return type. This makes sense for regular threads with an indeterminate lifetime. However, thestd::thread
module could also expose an explicitly unsafe way for spawning threads, with function signatures like the following:and (for the free-standing version)
Since the implementation of of
Builder::spawn
relies on unsafe code itself and thestd::sys::thread
types/functions don't require'static
lifetime bounds (haven't checked for all), this should be comparatively easy to implement by refactoring thespawn
implementation intospawn_unchecked
and calling that function with'static
lifetime bounds for the safe API.The benefits would mainly be:
Currently, scoped thread implementations have to use a lot of tricks with their return types and lifetime transmuting to get to work. Results have to be separately allocated and internally set instead of using the
std::thread::JoinHandle
type, which would be much more fitting if not for the lifetime bounds on thespawn
functions.To summarize, scoped threads could be implemented more safely and with fewer allocations.
The text was updated successfully, but these errors were encountered: