Le 17/02/2021 à 05:20, Micah Kornfield a écrit : >> >> If a method could potentially run some kind of long term blocking I/O >> wait then yes. So reading / writing tables & datasets, IPC, >> filesystem APIs, etc. will all need to adapt. It doesn't have to be >> all at once. CPU only functions would remain as they are. So table >> manipulation, compute functions, etc. would remain as they are. For >> example, there would never be any advantage to creating an >> asynchronous method to drop a column from a table. > > > My main concern is around the "viralness" of Futures. I think they are good > in some cases but can become hard to reason about/error prone if you aren't > used to working with them day in/out. I don't have any concrete > recommendation at this point, just something we should be careful about > when doing the refactoring.
I think it's ok to expose synchronous facades at key points in the Arrow API, to avoid having to deal with futures when you don't need to. Regards Antoine.
