crepererum commented on code in PR #15030:
URL: https://github.com/apache/datafusion/pull/15030#discussion_r1984720627
##########
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
Review Comment:
> In the current architecture of datafusion, we are only introduced with
Pending results because of an IO work. So, tasks can only yield at IO points
(there are a few exceptions).
This is not true, we already do cooperative yielding, see #5299 and the bug
report that was linked in there.
##########
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
Review Comment:
I vote for leaving it in or at least put it back once the relevant tokio
version is relased. It's a reasonable API with a reasonable behavior. If you
wonder how much you use it, that question is something you also need to answer
for every other `Pending` check/counter. So only because it doesn't give you an
universal answer doesn't mean it's an inappropriate tool.
##########
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).
I think we can state that if you work packages are record batches and your
compute complexity is linear (like filter and map/project operation), then you
probably don't need this. But if you do any form of aggregation or super-linear
behavior (e.g. unnest, data decompression), then you must think about that
issue.
--
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
