[ImageJ-devel] when to close cursors, was Re: [fiji-devel] imglib coding style

[Stephan Preibisch]

> As I said---I was tired :)  

Me too now :) I was super lucky to arrive before the great Icelandic volcano ashes I read :)

> I thought about not locking cells at all
> and
> delivering a copy of the data for each cursor independently which then
> would be deleted automatically on cursor death but that violates data
> persistence for many cursors accessing the same data.  So we need an
> external instance providing the paged data in a single instance and,
> therefore, the close construct.

That makes perfect sense but would not support writing data to the container, just to the copy of the Type ... this is fine for a read-only container like the ShapeList but not for "normal" images I would say ...

> Deleting the cursor the Java way would delete the Cache too, Caches on
> container- or image-level would need the close construct though.  

But not if it is some kind of data lying on the harddisk ... or if it might use write-caching (maybe writing to a web-resource in blocks rather than single operations)

> For constraining the number of cursors allowed to run in parallel, I cannot
> figure out a proper reason.

Maybe only one cursor at a time is allowed to be fast and not need synchronization? Or for the write-cache ...

I guess my point is, a cursor.close() does not really harm and but most importantly does not limit anything what can be programmed with. We need it for images and containers anyways and it is somehow consistent in that way. 

And it makes the code more structured IMHO, it is clearer where the validity of a cursor ends...

> 
> Still, Image collects the cursors working on it but never removes them,
> this needs to be fixed.
> 

I completely agree on that one, this needs fixing! I had it initially to be able to close all cursors of an image for paged cells...

Ciao ciao, Steffi