carols10cents commented on code in PR #15030:
URL: https://github.com/apache/datafusion/pull/15030#discussion_r1983660228


##########
datafusion/physical-plan/src/execution_plan.rs:
##########
@@ -260,13 +260,30 @@ pub trait ExecutionPlan: Debug + DisplayAs + Send + Sync {
     /// used.
     /// Thus, [`spawn`] is disallowed, and instead use [`SpawnedTask`].
     ///
+    /// To enable timely cancellation, the [`Stream`] that is returned must not
+    /// pin the CPU and must yield back to the tokio runtime regularly. This 
can
+    /// be achieved by manually returning [`Poll::Pending`] in regular 
intervals,
+    /// or the use of [`tokio::task::yield_now()`]. Cooperative scheduling may 
also
+    /// be a way to achieve this goal, as [tokio support for it 
improves][coop].
+    /// Determination for "regularly" may be made using a timer (being careful 
with
+    /// the overhead-heavy syscall needed to take the time) or by counting 
rows or
+    /// batches.
+    ///
+    /// The goal is for `datafusion`-provided operator implementation to
+    /// strive for [the guideline of not spending a long time without reaching

Review Comment:
   I'm not sure if I'm understanding what you're saying correctly-- but I 
believe datafusion _does_ need this as demonstrated by [the cancellation 
benchmarks I recently added](https://github.com/apache/datafusion/pull/14818) 
that show there's at least one case where it takes 32ms (on @alamb's machine) 
to cancel/drop the runtime because there are operations that aren't yielding 
often enough (the guidelines I've seen suggest aiming for 1ms of work between 
yield points).
   
   There are also issues such as 
https://github.com/apache/datafusion/issues/14036 where queries aren't able to 
be cancelled, and the root cause also appears to be not yielding often enough.
   
   Could you elaborate on why you _don't_ think datafusion needs manual yields, 
based on the behavior of the benchmarks and uncancellable query issues?



-- 
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: github-unsubscr...@datafusion.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: github-unsubscr...@datafusion.apache.org
For additional commands, e-mail: github-h...@datafusion.apache.org

Reply via email to