ozankabak commented on code in PR #15030:
URL: https://github.com/apache/datafusion/pull/15030#discussion_r1984080469
##########
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 think what he means is that in most cases a manual yield shouldn't be
necessary for CPU-bound operators in most cases (not all). It is possible for
this to be necessary in certain situations (very large batch sizes, operator
does superlinear-complexity work w.r.t. batch size etc.), but it shouldn't be a
common situation. I think the documentation should probably state this, and
give some concrete examples when manual yielding may be necessary.
--
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
