You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Please describe your wishes and possible alternatives to achieve the desired result.
After #1726 people will be able to have zarr return async compatible arrays. We can update all of our internal io to pool requests together using asyncio.gather and give us more throughput, especially for cloud-based analysis.
Internally use async for the registered reading classes
Make a public async version of read_elem
Make a public async version of read_lazy/read_elem_lazy
Make a public async version of read_zarr/read_h5ad
The text was updated successfully, but these errors were encountered:
The main issue here is the interplay between read_dispatched and the underlying methods in methods,py which call _Reader.read_elem (thus hooking back into the callback from read_dispatched). With a single set of methods.py that are all async, the functions hook into read_elem_async which can be problematic if callback is synchronous. Thus we probably need either a really clean compat layer (not sure what this would look like, another argumet? but then you just have giant if-then blocks?) or more-or-less duplciated functions
Please describe your wishes and possible alternatives to achieve the desired result.
After #1726 people will be able to have zarr return async compatible arrays. We can update all of our internal
io
to pool requests together usingasyncio.gather
and give us more throughput, especially for cloud-based analysis.async
for the registered reading classesasync
version ofread_elem
async
version ofread_lazy
/read_elem_lazy
async
version ofread_zarr
/read_h5ad
The text was updated successfully, but these errors were encountered: