Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I've found this sort of function helpful when trying to avoid a Barbara Battles Buffered Streams type situation; specifically in my case, when you have a select-loop and one of the branches needs to await, but you don't want to starve something from another branch (pseudocode):
Without that
.also_poll(&mut fut)
,fut
would be starved of polls for the duration ofhandle_stream_item
, potentially causing deadlocks or very long delays through the rest of the system iffut
was queued to receive a semaphore permit (e.g. a mutex, a mpsc send() permit) because now it can't release it untilhandle_stream_item
is done. That was my specific use case, at least, but I feel that this is a valuable primitive to have in general as folks start to look at stuff likeStream::poll_progress
for combating BBBS (.also_poll(poll_fn(|cx| foo.poll_progress(cx)))
is I feel a quintessential potential use case for this function).Definitely open to naming suggestions, I feel like as it is it might not be super intuitive, but I do like how
foo.also_poll(bar).await
reads.