tustvold commented on code in PR #6310:
URL: https://github.com/apache/arrow-datafusion/pull/6310#discussion_r1188801003
##########
datafusion/core/src/physical_plan/repartition/mod.rs:
##########
@@ -532,9 +541,28 @@ impl RepartitionExec {
timer.done();
}
- // If the input stream is endless, we may spin forever and never
yield back to tokio. Hence let us yield.
- // See https://github.com/apache/arrow-datafusion/issues/5278.
- tokio::task::yield_now().await;
+ // If the input stream is endless, we may spin forever and
Review Comment:
You could use https://docs.rs/tokio/latest/tokio/task/fn.consume_budget.html
but I'm honestly a little confused by this. "we may spin forever" would imply
an issue with unbounded receivers, not an issue with the repartition operator?
TLDR I'd vote to not yield at all, I don't agree that this fixes #5278
rather just papers over it with a dubious fix
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
