gcsfs
gcsfs copied to clipboard
Use aiofiles to avoid blocking file functions
related #405
I thought perhaps someone other than me might have some opinions here. I'm not certain gcsfs (or any of the fsspec async implementations) wants to take on the extra dependency. It seems unlikely to me that latency in the local filesystem will ever be important compared to waiting on the network.
Furthermore, and I might be wrong here, but my impression is that file calls are fundamentally blocking, and aiofiles (and friends) emulate async by dispatching to threads.
First things first, don't aiofiles
apply to local files? gcsfs
is used for remote files on Google Cloud Storage, so wouldn't it make sense to think about this in the fsspec
local file context?
Besides that, I agree with @martindurant on being unnecessary for local disk + local files in sync applications. However, having coroutines for file operations using aiofiles
may be useful in async app cases and will make it more convenient for downstream developers (i.e. fastapi app using a local file as a cache via fsspec
and also using gcsfs
to access the cloud storage, with the same non-blocking async APIs).
P.S. I am a little confused. This PR shows up in gcsfs
; however, it is merging into fsspec
, but editing gcsfs
code.
it is merging into fsspec, but editing gcsfs code.
Here, fsspec
is the org, so it means merging into fsspec/gcsfs:main
it is merging into fsspec, but editing gcsfs code.
Here,
fsspec
is the org, so it means merging intofsspec/gcsfs:main
Ah I see. It seems like PRs from forks do that. Learn something new everyday :)