CUDAStreamView (or similar name) object

[jakirkham]

Just like in the array case, where there are many different ways to define an array (Python Buffer Protocol, __array_interface__, __cuda_array_interface__, DLPack, etc.), there is a similar issue with streams up to this point. To provide a few examples...

• Python __dlpack__ can contain a stream
  • Specify synchronization semantics dmlc/dlpack#57
• Numba's __cuda_array_interface__ can contain a stream
  • Discussion: should __cuda_array_interface__ include a stream pointer? numba/numba#4933
• Plus a number of libraries provide their own stream objects
  • torch.cuda.stream
  • cupy.cuda.Stream
• Not to mention cases where a cudaStream_t is passed around as an integer address

With all these objects floating around that provide different APIs, there remains a need to wrangle them them into some kind of common object and that has proper RAII semantics and can be used in a standard way

A CUDAStreamView, much like the StridedMemoryView, would help provide this standard way to consume these different objects and provide a standard object and API to use (including __cuda_stream__)

It could...

1. Identify the object
2. Keep a copy of the cudaStream_t in an attribute
3. Keep a reference to the exporting object
4. Query/store any other relevant info

[leofang]

The goal of cuda.core is to not bifurcate the CUDA-owned objects in each Python project, and instead new projects should just use cuda.core and get streams.

For established projects, we already have (by design) __cuda_stream__ + Device.create_stream for wrapping a foreign stream object, so I do not think there's anything extra that cuda.core needs to do, other than helping/educating/urging existing Python projects to implement __cuda_stream__.
https://nvidia.github.io/cuda-python/cuda-core/latest/generated/cuda.core.experimental.Device.html#cuda.core.experimental.Device.create_stream

[vyasr]

The main possible value-add that I see is having a standard vocabulary type for processing objects that expose the protocol. Essentially if my lib exposes a function foo that takes a stream, the protocol approach would have you do this:

# lib.py
def foo(..., stream_like):
    if not hasattr(stream_like, "__cuda_stream__"):
        raise ValueError("Invalid stream object")
    stream = process_stream_like(stream_like.__cuda__stream__) # This function needs to be defined.

A standard view type in cuda.core would replace the need for process_stream_like.

from cuda.core import StreamView
def foo(..., stream_like):
    stream = StreamView(stream_like)

It's definitely not a requirement though, just a convenience.

[leofang]

I think this issue was discussed in one of the design meetings last year. The conclusion was the same: We already have everything asked here in cuda.core, so inventing new types does not solve additional problems. For Vyas's example we can just do:

from cuda.core import Device:

def foo(..., stream_like):
    # this works as long as stream_like supports __cuda_stream__
    stream = Device().create_stream(stream_like)

https://nvidia.github.io/cuda-python/cuda-core/latest/generated/cuda.core.experimental.Device.html#cuda.core.experimental.Device.create_stream

[leofang]

A few more words on the design principle behind this and other topics: It is clear (at least to me 🙂) in 2025 that we want not only a data exchange protocol to communicate across library boundary, but also a concrete implementation of the said protocol, so that everyone can focus on getting the job done without re-implementing the protocol support (DLPack example), which can be non-trivial and sometimes error prone. It is the reason we provide StridedMemoryView (a DLPack consumer implementation) and .create_stream(obj, ...) (a CUDA stream implementation).