We can avoid giving up the implicit token when creating the Rayon thread pool by changing the semantics of
build_scoped so that it inherits the token from the caller and gives it to the first Rayon thread and also let the first Rayon thread execute the passed closure.
@simulacrum Are you planning to fix this by not letting rustc return all tokens to cargo when you have a channel to each rustc process?
It was our impression that a fix inside rayon is possibly non trivial or might point at deeper questions.
Current plan I believe is to keep track of the token count and just not release/acquire the first token, which should be relatively easy to implement hopefully.
In particular I think @nikomatsakis was not sure about whether this is pointing at some underlying problem with rayon or if it's something we should try to patch over ourselves.
What you're proposing loosely sounds like a more invasive but maybe also more principled change.
Though we do have the query latch which I think has the same problem as rayon
(but not exactly sure there, since it is semi-plausible that we can't run into trouble there as we don't have a situation where all threads latch, but I'm not confident)
It's not that principled. It only fixes one case where it could happen. It can also happen when the main thread is waiting on some other thread.
well, it's fine if the main thread releases its token
we just can't have a rustc without tokens