Tracking Issue for thread spawn hooks

[m-ou-se]

Feature gate: #![feature(thread_spawn_hook)]

This is a tracking issue for thread spawn hooks as proposed in rust-lang/rfcs#3642

Public API

// std::thread:

pub fn add_spawn_hook<F, G>(hook: F)
where
    F: 'static + Send + Sync + Fn(&Thread) -> G,
    G: 'static + Send + FnOnce();

impl Builder {
    pub fn no_hooks(mut self) -> Builder;
}

Steps / History

• RFC: [RFC] Thread spawn hook (inheriting thread locals) rfcs#3642
• Implementation: Add std::thread::add_spawn_hook. #125405
• Final comment period (FCP)
• Stabilization PR

Unresolved Questions

• Should the return value of the hook be an Option, for when the hook does not require any code to be run in the child?
• Should the hook be able to access/configure more information about the child thread? E.g. set its stack size.
• What should we do when threads are spawned after TLS destruction? (E.g. in an atexit() handler.) Panic? (std::thread::spawn: thread-local storage panics #138696) Or skip them? (Allow spawning threads after TLS destruction #138702)
• Giving the hook access to &Thread before the thread has finished initializing means it can't observe the thread ID in most cases. Is that the right behavior?

[Erk-]

Before this is stabilized there should be documentation added about panics in the places where it makes sense which I think would be std::thread::spawn, std::thread::Scope::spawn and std::thread::Builder::{spawn, spawn_scoped}.

I don't think it is appropriate to add it yet since it is a experimental feature still.

[AhoyISki]

I very badly need this feature stabilized for an API that I'm working on. Hopefully the pull request above is enough documentation for the concern brought up.

[nicola-gigante]

Hi!

Any news on this feature? It would be extremely helpful for a use case I have. Can I help in any way to move this forward?