bkietz commented on code in PR #37365:
URL: https://github.com/apache/arrow/pull/37365#discussion_r1308938395
##########
cpp/src/arrow/gpu/cuda_context.h:
##########
@@ -140,6 +142,71 @@ class ARROW_EXPORT CudaDevice : public Device {
/// \param[in] size The buffer size in bytes
Result<std::shared_ptr<CudaHostBuffer>> AllocateHostBuffer(int64_t size);
+ /// \brief EXPERIMENTAL: Wrapper for CUstreams
+ ///
+ /// Does not *own* the CUstream object which must be separately constructed
+ /// and freed using cuStreamCreate and cuStreamDestroy (or equivalent).
+ /// Default construction will use the cuda default stream, and does not allow
+ /// construction from literal 0 or nullptr.
+ class ARROW_EXPORT Stream : public Device::Stream {
+ public:
+ explicit Stream(std::shared_ptr<CudaContext> ctx) noexcept
+ : context_{std::move(ctx)}, stream_{} {}
+
+ ~Stream() = default;
+ explicit Stream(std::shared_ptr<CudaContext> ctx, CUstream stream) noexcept
+ : context_{std::move(ctx)}, stream_{stream} {}
Review Comment:
I think I missed something: why does Stream need to own instead of just
wrap? It seems that stream lifetime management will *always* be handled
elsewhere. For example, say there's an application built with CUDA which is
adding an arrow integration: the application will already have a pool of
CUstreams which only need to be wrapped in arrow Device::Streams when calling
an arrow function. I don't think an arrow function will ever take ownership of
the stream away from the hypothetical application, so to me it seems we don't
need arrow functions to wrap them in smart pointers for dynamic lifetimes or
functions for producing new streams (MakeStream).
To put this another way: would we ever need to produce a
`vector<shared_ptr<Stream>>` where the wrapped streams are a mix of `CUstream`
and `hipStream_t`? Even if an application were using both ROCM and CUDA at the
same time, the streams would (I'm certain) be maintained in separate pools
which obviates the need for polymorphic lifetime management.
--
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]
