# Should JoinHandle\<T\> (from std::thread) implement Future?

**URL:** <https://internals.rust-lang.org/t/should-joinhandle-t-from-std-thread-implement-future/10807>\
**Category:** Uncategorized\
**Created:** [August 17, 2019, 2:15pm UTC](https://internals.rust-lang.org/t/should-joinhandle-t-from-std-thread-implement-future/10807 "2019-08-17T14:15:56Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![lachlansneff](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/lachlansneff/32/5924_2.png) [@lachlansneff](https://internals.rust-lang.org/u/lachlansneff)\
**Post date:** [August 17, 2019, 2:15pm UTC](https://internals.rust-lang.org/t/should-joinhandle-t-from-std-thread-implement-future/10807/1 "2019-08-17T14:15:56Z")

</div>

I think it would sense for `std::thread::JoinHandle` to implement `Future` because it would simplify the interaction between async code and threading.

For example, this would be valid:

```rust
/// Do some tough problem without blocking the threadpool.
async fn do_something_expensive() -> Result<HardToComputeValue, Error> {
    thread::spawn(|| {
        // do something difficult ...
    }?.await;
}

```

---

<div class="post-metadata">

**Author:** ![dhm](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/dhm/32/4879_2.png) [@dhm](https://internals.rust-lang.org/u/dhm)\
**Post date:** [August 17, 2019, 4:20pm UTC](https://internals.rust-lang.org/t/should-joinhandle-t-from-std-thread-implement-future/10807/2 "2019-08-17T16:20:31Z")

</div>

Although it does not do exactly what you mean, [`::tokio_threadpool::blocking()`](https://docs.rs/tokio-threadpool/0.1.15/tokio_threadpool/fn.blocking.html) offers functionality for a very similar need (the difference being in how and for what purpose the additional thread is spawned).

---

<div class="post-metadata">

**Author:** ![Matthias247](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/matthias247/32/5734_2.png) [@Matthias247](https://internals.rust-lang.org/u/Matthias247)\
**Post date:** [August 17, 2019, 5:51pm UTC](https://internals.rust-lang.org/t/should-joinhandle-t-from-std-thread-implement-future/10807/3 "2019-08-17T17:51:27Z")

</div>

This wouldn’t work in an efficient fashion since JoinHandle only supports a blocking wait. Which would mean the whole executor gets blocked until the thread finished when await is called.

To fix this JoinHandle and spawn() need to be changed to be able to interact with Wakers. That is extra overhead that isn’t required for projects which don’t use Futures.

Apart from that runtimes will also offer threadpools which offer the functionality you like to see. So there is no strong need to have this on the general purpose std::thread

---

<div class="post-metadata">

**Author:** ![bill\_myers](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/bill_myers/32/4085_2.png) [@bill\_myers](https://internals.rust-lang.org/u/bill_myers)\
**Post date:** [August 19, 2019, 11:26am UTC](https://internals.rust-lang.org/t/should-joinhandle-t-from-std-thread-implement-future/10807/4 "2019-08-19T11:26:17Z")

</div>

Yeah, you can't do that because there is no async join API in pthreads.

You could maybe implement it using the pidfd API plus an epoll reactor in Linux, but it's not very efficient since it requires unnecessary system calls and also only works on recent Linux kernels and not portable to other POSIX systems.

Instead, create a oneshot future and have the spawned thread complete it, like this

```rust
let (c, p) = oneshot();

thread::spawn(|| {
    [...]
    c.complete(());
})?;

p.await

```

---

<div class="post-metadata">

**Author:** ![system](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/system/32/14092_2.png) [@system](https://internals.rust-lang.org/u/system)\
**Post date:** [November 17, 2019, 11:37am UTC](https://internals.rust-lang.org/t/should-joinhandle-t-from-std-thread-implement-future/10807/5 "2019-11-17T11:37:53Z")

</div>

Closed on November 17, 2019, 11:37am UTC

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.