Any alternative threadpool to rayon?

I'm recently surveying the threadpool ecosystems in Rust. And much to my surprise, most of threadpool implementations seem to lack an important feature. That is:

(https://docs.rs/rayon/1.7.0/rayon/fn.join.html)

.... When \join\\ is called within the pool, the calling thread still actively participates in the thread pool. It will begin by executing closure A (on the current thread)...... if however closure B has been stolen, then it will look for other work while waiting for the thief to fully execute closure B.

In short, the ability to non-blockingly suspend and yield to the threadpool within the pool.

Without this ability, spawning and awaiting another work item within the threadpool (either with channels or barriers) will very likely lead to deadlocks. This basically rules out the possibility to "spawn a structured work tree where each node awaits its children".

A few threadpool implementations I've surveyed so far:

1. threadpool: Requires a channel to send back results. \join\\ will deadlock if called within the pool.
2. scheduled-thread-pool: Requires a channel to send back results.
3. scoped\_threadpool: Has a \scope\\ API but uses blocking channel when it drops.
4. rusty\_pool: Has a \JobHandle\\ API but uses blocking channel under the hood. Has a \join\\ API but uses blocking \CondVar\\ under the hood.
5. threads\_pool: Requires a channel to send back results.

This list goes on. Rayon just seems to be the sole survivor here.

It's strange to consider all the threadpool implementations missed this feature. I might have made a mistake or overlooked a popular crate. I would like to hear your advice.