-
Notifications
You must be signed in to change notification settings - Fork 90
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
CellRandomAccess unexpectedly loads neighboring cells #252
Comments
Thanks for raising this issue @igorpisarev. I talked to @axtimwalde earlier and he said that he was having a look at the |
I think I found another place where this hits one quite badly. It is in the
Just for getting one random access to one slice of the data, below loop "touches" all slices:
The issue is that with the current implementation of |
Previously the CellRandomAccess would link Cell data to the Type as soon as the RA is positioned in a new Cell. Specifically, for LazyCellImgs this would trigger loading of the Cell (potentially unnecessary). This addresses #252.
Previously the CellRandomAccess would link Cell data to the Type as soon as the RA is positioned in a new Cell. Specifically, for LazyCellImgs this would trigger loading of the Cell (potentially unnecessary). This addresses #252.
Let's say a
CellImg
is defined with cell size[2,2,2]
, and we want to iterate frommin=[4,4,4]
tomax=[5,5,5]
in this image. This interval covers exactly one cell at grid position[2,2,2]
.However, looping over this interval using
unexpectedly leads to loading 3 extra cells:
This behavior becomes problematic in a workflow when the cells are read and written concurrently as it subtly introduces race conditions.
I also created an example demonstrating this behavior using N5 as a cell storage backend: https://gist.github.com/igorpisarev/591212a26228e4ac7cb482b0134217a1
The text was updated successfully, but these errors were encountered: