-
-
Notifications
You must be signed in to change notification settings - Fork 282
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[v3] SyncError: Calling sync() from within a running loop #2133
Comments
@normanrz - curious if you have ideas for how to address this? |
Seems like a tricky problem. We could solve this for specific use cases. For example, in the |
asyncio is not re-entrant, but nest-asyncio does exist (if "archived"). It is not a solution for us, because it would patch system libraries that users might be depending on. Conversely, the dask way to deal with this is for a (non-async) function to detect if it is being called within an active event loop or not, so that when it calls async code, it can either pass back the coroutine to the caller, or sync() it. The fsspec way to deal with this, is to have a separate sync API: every async method has another function which calls sync() on it, so that the calling code must decide which variant to call. This is how you might end up with a sync-minded fs instance and an async one, which are otherwise identical (they used to have different init behaviour, but not any more). |
A simplified version of what dask does is in streamz. I haven't actually checked that dask still works this way, now that I think about it! |
Zarr version
'3.0.0a2.dev5+g8446607e.d20240827'
Numcodecs version
0.13.0
Python Version
3.11
Operating System
Mac
Installation
pip
Description
Indexing a zarr array with another zarr array causes our
sync
method to be called inside anothersync
call.Steps to reproduce
Produces this traceback 👇
Additional output
No response
The text was updated successfully, but these errors were encountered: