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 > > > >> > > > > > > > > > > >
