Currently, the `rt_threaded::lifo_stealable` test I added in #7431
spawns an additional task which sleeps on a 4ms timer in a loop. This
ensures that no worker remains permanently parked. This was added
because it was necessary to stop the LIFO slot deadlock from occurring
prior to changes in the logic for determining whether to notify another
worker, which is what @Darksonn was referring to in [this comment][1].
Removing the `churn()` test makes the test actually validate that
another worker is notified to steal the LIFO task, and that the changes
from #7431 will *always* prevent a LIFO slot deadlock, regardless of the
behavior of other tasks on the runtime. See also [this comment][2] for
further discussion.
[1]: https://github.com/tokio-rs/tokio/pull/7431#discussion_r2184724657
[2]: https://github.com/tokio-rs/tokio/pull/8069#issuecomment-4274244723
In #7431, I originally implemented `AtomicNotified` with the `AcqRel`
atomic ordering, which is all that *should* be necessary here. While
trying to debug a failing test on ARM, I changed it to `SeqCst`. This
fixed the test, but was not actually necessary to solve the root cause
of that test failure, which was ultimately fixed in #8008 instead. Using
`SeqCst` here and locking the bus probably increases the overhead of
using the LIFO slot substantially, so I've un-done that.
This commit puts back the change to allow stealing tasks from the LIFO
slot, which was originally introduced in #7431. This change was reverted
in 9605999c0a70e43ff27dfddd7e9dc5bb1869efbe in order to fix the
performance regression due to increased cross thread wakeups (#8065).
Previously, pushing a task to an unoccupied LIFO slot would not notify a
parked worker, but when #7431 made the LIFO slot stealable, we started
notifying in that case, which increases runtime overhead. Therefore, the
change was reverted in v1.52.2. This commit reintroduces it.
Subsequent commits on this branch will allow configuring whether LIFO
slot pushes wake a parked worker, so that we can allow stealing from
the LIFO slot while making the increased wakeup overhead opt-in.
Closes#4941
`MapWhile` is intentionally excluded because its current implementation
does not track when the closure returns `None` early, making a correct
`is_terminated()` impossible without a separate semantic change.
Currently, the `rt_threaded::lifo_stealable` test I added in #7431
spawns an additional task which sleeps on a 4ms timer in a loop. This
ensures that no worker remains permanently parked. This was added
because it was necessary to stop the LIFO slot deadlock from occurring
prior to changes in the logic for determining whether to notify another
worker, which is what @Darksonn was referring to in [this comment][1].
Removing the `churn()` test makes the test actually validate that
another worker is notified to steal the LIFO task, and that the changes
from #7431 will *always* prevent a LIFO slot deadlock, regardless of the
behavior of other tasks on the runtime. See also [this comment][2] for
further discussion.
[1]: https://github.com/tokio-rs/tokio/pull/7431#discussion_r2184724657
[2]: https://github.com/tokio-rs/tokio/pull/8069#issuecomment-4274244723
Add a Notes section to all five try_* methods on pipe::Sender and
pipe::Receiver explaining that the runtime's I/O driver only delivers
readiness events after control is yielded back to it, so calling
try_read/try_write before any .await returns WouldBlock even when the
operation could otherwise succeed.
This is the same readiness model used by every other Tokio I/O type;
the pipe docs simply did not previously call it out. Refs #7625.
---------
Co-authored-by: Mattia Pitossi <[email protected]>
This reverts commit 1604bc3351.
Unfortunately, this commit introduced a regression that causes programs
using `spawn_blocking` to hang (see #8056). To fix the regression, we
need to undo this change and publish a v1.52.1 release as soon as
possible.
In the future, we may wish to bring back a sharded queue for
`spawn_blocking` tasks, either based on the implementation added in
#7757 or a new one. However, since this is a substantial change to the
runtime internals, I think such a change should probably be done as an
unstable, opt-in `tokio::runtime::Builder` setting initially, so that we
don't regress existing users. I had hoped we could do this now, but
unfortunately, the sharded queue implementation from #7757 is kind of
tightly coupled with the rest of the `spawn_blocking` machinery and
cannot be easily swapped out --- and the hang still occurs with
`NUM_SHARDS` set to 1, so there isn't an easy way to turn it on and off.
Therefore, in the interest of getting a fix out ASAP, this is just a
simple revert.
Fixes#8056
Eliza Weisman