You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
What actually happens is that tx.blocking_send and friends start to give errors, and the caller-provided closure is responsible for returning when that happens.
It's probably worthwhile checking whether this is also true for the async variant, or whether it actually aborts the tokio task at any await point.
It seems to me that a blocking task is actually aborted / cancelled on drop, but once a blocking task starts it can't be interrupted.
So for example, if the task hasn't started yet it will never start. However, once the blocking task starts running, it will run to completion as it never yields control back to tokio (via await)
Describe the bug
https://docs.rs/datafusion/latest/datafusion/physical_plan/stream/struct.RecordBatchReceiverStreamBuilder.html#method.spawn_blocking docs say
There's no aborting happening, and I don't think one can do that safely (no abort in https://doc.rust-lang.org/std/thread/struct.Thread.html).
What actually happens is that
tx.blocking_send
and friends start to give errors, and the caller-provided closure is responsible for returning when that happens.It's probably worthwhile checking whether this is also true for the async variant, or whether it actually aborts the tokio task at any await point.
https://docs.rs/tokio/latest/tokio/sync/mpsc/struct.Sender.html#method.blocking_send
To Reproduce
Expected behavior
The behavior makes sense, but should be documented.
Additional context
No response
The text was updated successfully, but these errors were encountered: