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