File tree 1 file changed +37
-0
lines changed
rayon-core/src/thread_pool 1 file changed +37
-0
lines changed Original file line number Diff line number Diff line change @@ -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
+ /// fn main() {
94
+ /// rayon::ThreadPoolBuilder::new().num_threads(1).build_global().unwrap();
95
+ /// let pool = rayon_core::ThreadPoolBuilder::default().build().unwrap();
96
+ /// let do_it = || {
97
+ /// print!("one ");
98
+ /// pool.install(||{});
99
+ /// print!("two ");
100
+ /// }
101
+ /// rayon::join(|| do_it(), || do_it());
102
+ /// }
103
+ /// ```
104
+ ///
105
+ /// Since we configured just one thread in the global pool, one might
106
+ /// expect `do_it()` to run sequentially, producing:
107
+ ///
108
+ /// ```ascii
109
+ /// one two one two
110
+ /// ```
111
+ ///
112
+ /// However each call to `install()` yields implicitly, allowing rayon to
113
+ /// run multiple instances of `do_it()` concurrently on the single, global
114
+ /// thread. The following output would be equally valid:
115
+ ///
116
+ /// ```ascii
117
+ /// one one two two
118
+ /// ```
119
+ ///
83
120
/// # Panics
84
121
///
85
122
/// If `op` should panic, that panic will be propagated.
You can’t perform that action at this time.
0 commit comments