@@ -80,6 +80,43 @@ impl ThreadPool {
80
80
/// thread-local data from the current thread will not be
81
81
/// accessible.
82
82
///
83
+ /// # Warning: execution order
84
+ ///
85
+ /// If the current thread is part of a different thread pool, it will try to
86
+ /// keep busy while the `op` completes in its target pool, similar to
87
+ /// calling [`ThreadPool::yield_now()`] in a loop. Therefore, it may
88
+ /// potentially schedule other tasks to run on the current thread in the
89
+ /// meantime. For example
90
+ ///
91
+ /// ```rust
92
+ /// # use rayon_core as rayon;
93
+ /// use rayon::iter::{IntoParallelIterator, ParallelIterator};
94
+ /// fn main() {
95
+ /// rayon::ThreadPoolBuilder::new().num_threads(1).build_global().unwrap();
96
+ /// let pool = rayon::ThreadPoolBuilder::default().build().unwrap();
97
+ /// (0..3).into_par_iter().for_each(|_| {
98
+ /// print!("one ");
99
+ /// pool.install(||{});
100
+ /// print!("two ");
101
+ /// });
102
+ /// }
103
+ /// ```
104
+ ///
105
+ /// Since we configured just one thread in the global pool, one might
106
+ /// expect this to run sequentially, producing:
107
+ ///
108
+ /// ```ascii
109
+ /// one two one two one two
110
+ /// ```
111
+ ///
112
+ /// However each call to `install()` yields implicitly, allowing rayon to
113
+ /// run several instances of the `for_each()` loop concurrently on the
114
+ /// single, global thread. The following output would be equally valid:
115
+ ///
116
+ /// ```ascii
117
+ /// one one two one two two
118
+ /// ```
119
+ ///
83
120
/// # Panics
84
121
///
85
122
/// If `op` should panic, that panic will be propagated.
0 commit comments