Consider making std::thread::Builder reusable

Opened by Carl Lerche at 2021-02-11 03:20:04

Consider making std::thread::Builder reusable or have a reusable variant. This would be a helpful construct to use as part of a thread pool or any other abstraction that spawns threads.

This should be easy to do once we drop stdout and stderr.
Aaron Turon at 2015-01-17 21:27:05
Triage: no change.
Steve Klabnik at 2015-11-04 16:26:14
I don't see stdout and stderr inside thread::Builder itself, so it seems like we could do this now with little difficulty, though I may be missing some detail.
Mark Rousskov at 2017-06-14 21:07:01
stdout and stderr methods have gone away since d4a2c94. Changing self to &self in spawn will not break any existing code(I think).
Wonwoo Choi at 2017-06-15 06:12:21
Once concern is that we need the String name contained by-value, not a reference to it, but that feels like a relatively minor concern to me. We can definitely implement Clone for Builder, though, I think, as the first (and perhaps only) step here. @rust-lang/libs Can we get pre-approval for implementing Clone for the thread Builder? If so, then I can mentor/E-easy. I've included the builder struct below (in source it's here).
```
pub struct Builder {
    // A name for the thread-to-be, for identification in panic messages
    name: Option<String>,
    // The size of the stack for the spawned thread in bytes
    stack_size: Option<usize>,
}
```
Mark Rousskov at 2017-06-15 13:31:13
The one difficulty with Clone that I could think of is that you typically can't clone trait objects (e.g. closures). This is why, for example, Command does not implement Clone. We may be able to get around this though perhaps, as I've certainly found cloning builders historically to be useful.
Alex Crichton at 2017-06-15 14:55:55
I'm somewhat confused -- Builder doesn't store a closure, does it? So cloning it shouldn't be a problem...?
Mark Rousskov at 2017-06-15 15:21:21
Builder only specifies the thread name and the stack size. Thread body is given when spawn is called, so cloning the Builder shouldn't be a problem.
Wonwoo Choi at 2017-06-15 15:29:20
Ah yes sorry to clarify I mean for future expansion of builder methods. At Rust 1.0.0 the Command type did not contain any closures but it's since picked some up. If we add Clone here we'd just want to be sure that we'd never want to add some sort of callback to the builder.
Alex Crichton at 2017-06-15 16:42:49
Then it'd be more desireable to add a reusable variant of Builder, or adding a method that clones the Builder without implementing Clone. Maybe we can add borrowing variant of spawn that calls callback if there's any, and then invalidates it, I think?
Wonwoo Choi at 2017-06-15 16:55:07
Suggestion that should be forwards compatible: a function that manually clones the builder, then calls that new builder's spawn. A single function can be deprecated and implementation adjusted.
Khionu Sybiern at 2019-10-25 06:44:52
It'd be interesting to see a concrete example where having a re-usable thread builder would be useful. It doesn't actually carry much state itself. Otherwise, since we don't tend to have re-usable builders in the standard library we can probably close this.
Ashley Mannix at 2021-02-10 21:02:00
My use case was to be able to spawn multiple threads with identical configurations and names. Atm, you have to wrap the builder with a function that creates the builder and calls spawn. Any library that spawns multiple threads automatically, including every async runtime that supports multiple threads, can use this.

Builders are good for two things: either branching logic in the construction process or re-usability. Given the limited data that is being used in the builder and the fact that it's not reusable atm, it's quite useless.
Khionu Sybiern at 2021-02-11 03:20:04