Repository navigation
Add stream callback support #311
Description
Activity
deprioritizing this as it could have some perf considerations when it comes to CUDA graphs
Following up on my question from yesterday, now that I have L20 time set aside for this.
#2058 covers the
cuLaunchHostFunc/host_launchpath and is assigned to @Andy-Jost. Is any independent scope still intended for #311, or should #311 be treated as covered by #2058? If it is covered, I will leave it alone and not open a duplicate implementation.If there is independent scope, this is the slice I would take — tests and contract only, no second public API and no host_launch work:
- Ordinary (non-graph) stream callbacks: prior work → callback → later work ordering on the same stream, and that enqueue returning is not treated as callback completion.
- Lifetime/ownership: the Python callable and user data stay valid while borrowed, owning vs borrowed stream handles do not double-free or free early, and the no-callback path does not regress.
- Multi-device / multi-stream isolation (2× L20 available here): per-stream local order asserted, with no claim about global order or parallelism between callbacks.
- Exception reporting through whatever mechanism the owner settles on for this path (unraisable hook, error sink, or a documented no-propagation contract), asserted in a subprocess so a failure cannot take the test runner with it.
@Andy-Jost: if you would rather keep the stream-callback regression tests with #2058, please say so and I will drop #311 entirely. If some of the four items above are outside your #2058 scope, I can take exactly that slice and nothing else.
- added a commit that references this issue
on Sep 24, 2026