Merge #997

997: Guard `par_bridge` against work-stealing recursion r=cuviper a=cuviper

It doesn't make sense for the `par_bridge` producer to run nested on one
thread, since each split is capable of running the entire iterator to
completion. However, this can still happen if the serial iterator or the
consumer side make any rayon calls that would block, where it may go
into work-stealing and start another split of the `par_bridge`. With the
iterator in particular, this is a problem because we'll already be
holding the mutex, so trying to lock again will deadlock or panic.

We now set a flag in each thread when they start working on the bridge,
and bail out if we re-enter that bridge again on the same thread. The
new `par_bridge_recursion` test would previously hang almost every time
for me, but runs reliably with this new check in place.


Co-authored-by: Josh Stone <cuviper@gmail.com>

Author: bors[bot]

Cargo.toml

@@ -1,6 +1,6 @@
 [package]
 name = "rayon"
-version = "1.6.0"
+version = "1.6.1"
 authors = ["Niko Matsakis <niko@alum.mit.edu>",
            "Josh Stone <cuviper@gmail.com>"]
 description = "Simple work-stealing parallelism for Rust"
@@ -20,7 +20,6 @@ exclude = ["ci"]
 
 [dependencies]
 rayon-core = { version = "1.10.0", path = "rayon-core" }
-crossbeam-deque = "0.8.1"
 
 # This is a public dependency!
 [dependencies.either]

RELEASES.md

@@ -1,3 +1,11 @@
+# Release rayon 1.6.1 (2022-12-09)
+
+- Simplified `par_bridge` to only pull one item at a time from the iterator,
+  without batching. Threads that are waiting for iterator items will now block
+  appropriately rather than spinning CPU. (Thanks @njaard!)
+- Added protection against recursion in `par_bridge`, so iterators that also
+  invoke rayon will not cause mutex recursion deadlocks.
+
 # Release rayon-core 1.10.1 (2022-11-18)
 
 - Fixed a race condition with threads going to sleep while a broadcast starts.