I think the only benefit of having an async non-device API is that it cleanly separates the experimentality of the two. It may just be projection on my part, but I feel like there's enough interest for an async API to be validated fairly quickly -- while it may be years before we feel comfortable declaring the device API to be complete.And it seems awkward to say of the current API that some of the features are considered complete while others are considered experimental. But it certainly is possible.
On Mon, Apr 6, 2026 at 12:14 PM Matt Topol <[email protected]> wrote: > There's a lot of discussion to be found around the design [1] where I > believe the decision was to avoid essentially duplicating the entire > definition and interface since it's trivially easy to use a CPU-memory > ArrowArray as an ArrowDeviceArray. The inconvenience of that wrapping was > decided to be less problematic than having to maintain the duplicate > definitions. > > I'm not heavily opposed to creating a duplicate that uses ArrowArray and > ArrowArrayStream, but I question the utility vs the maintenance cost. Aside > from avoiding the slight inconvenience of having to check the device_type > instead of assuming it is valid on the CPU, what is the perceived benefit > of adding a non-ArrowDeviceArray version of the async API? > > --Matt > > [1]: https://github.com/apache/arrow/pull/43632 > > > On Mon, Apr 6, 2026, 2:44 PM Dewey Dunnington <[email protected]> > wrote: > > > I would personally love an async version of the non-device API. A CPU > > wrapper around the ArrowDeviceArray is not particularly hard to > > implement but I share the sentiment that it was never implemented in > > enough independent places to have validation that its design can > > handle non-CUDA workflows. It also may be that nobody is interested in > > non-CUDA workflows and that could be good enough (no need to design > > for something nobody is interested in using). > > > > My only non-CUDA experience is with Metal...while a Metal > > implementation theoretically exists in nanoarrow (that still passes > > CI) [1], with the current ArrowDeviceArray design the buffer has to be > > page-aligned [1] and I couldn't find a way to get the sync event to > > work [2]. Also nobody has ever been interested and I never tried very > > hard to overcome any of that :) > > > > Cheers, > > > > -dewey > > > > [1] > > > https://github.com/apache/arrow-nanoarrow/blob/23fc93c5c57ae4fa05a85c8b81ff8a51cc168f46/src/nanoarrow/device/metal.cc#L313-L329 > > [2] > > > https://github.com/apache/arrow-nanoarrow/blob/23fc93c5c57ae4fa05a85c8b81ff8a51cc168f46/src/nanoarrow/device/metal.cc#L313-L329 > > > > On Wed, Apr 1, 2026 at 7:02 PM Curt Hagenlocher <[email protected]> > > wrote: > > > > > > I'm theoretically interested in this mostly because of the async stream > > > interface, which will in principle be the basis for async support in > > ADBC. > > > But given the lack of device-specific usage for the device API, I > wonder > > > whether we shouldn't consider adding async support to the non-device > API > > > after all? > > > > > > -Curt > > > > > > On Wed, Apr 1, 2026 at 12:08 AM Antoine Pitrou <[email protected]> > > wrote: > > > > > > > > > > > Agreed with Matt. The main concern is that we're not sure it's > > > > well-designed enough to cater to wider use cases (including non-CUDA > > > > devices). > > > > > > > > Regards > > > > > > > > Antoine. > > > > > > > > > > > > Le 01/04/2026 à 07:30, Matt Topol a écrit : > > > > > It's mostly still considered experimental mostly because of how > > small the > > > > > usage of it is. If we get more usage of the device interface and > more > > > > > systems using it, then I think it would be worth-while to make it > no > > > > longer > > > > > experimental. > > > > > > > > > > I know that it's in use by Nvidia cuDF and such, but until it's > been > > in > > > > use > > > > > by more than just cuDF and arrow C++, I'd be wary of letting it be > > marked > > > > > as no longer experimental. Despite how much I want to see it become > > more > > > > > widespread lol > > > > > > > > > > --Matt > > > > > > > > > > On Tue, Mar 31, 2026, 11:47 PM Curt Hagenlocher < > > [email protected]> > > > > > wrote: > > > > > > > > > >> According to the LLM I consulted, the C Device Data Interface was > > first > > > > >> introduced in Arrow 12.0 in April of 2023. Three years later, it's > > still > > > > >> marked as experimental. I've gone ahead and done the same in my > .NET > > > > >> implementation (Implement Arrow C device API by CurtHagenlocher · > > Pull > > > > >> Request #305 · apache/arrow-dotnet > > > > >> <https://github.com/apache/arrow-dotnet/pull/305>), but I wonder > at > > > > what > > > > >> point we will consider this to be non-experimental. > > > > >> > > > > >> (I don't know how much uptake it has, and I'm mostly working my > way > > > > through > > > > >> the spec towards the async stream interface that's based on it -- > > which > > > > >> clearly *is* still experimental based on the small number of > > > > >> implementations it has. I'm hoping to eventually contribute a Rust > > > > version > > > > >> of that in addition to a C# version.) > > > > >> > > > > >> Thanks, > > > > >> -Curt > > > > >> > > > > > > > > > > > > > > > >
