On Wed, 04 May 2011 16:30:44 +0000, OS wrote:
> That said, I imagine that we'd be better off just always holding a ref
> for every FileData in the current directory. On my machine, a FileData
> is 176 bytes and a GList is 24 bytes, so for a directory of 20,000
> images, we'd be spending 3.8MB holding FileDatas. That's nothing.
> Thoughts?
FWIW, and considering that the current refcounting in Geeqie is
troublesome, you've got my blessing. :-) I'm all for a central list of
the current directory's file data objects, with added maintenance
structures on top of that.
Even with the couple of patches I've added to the tracker, there's at
least one code path that sometimes (but rarely) unrefs FileData and crashes.
One fundamental problem I see is that the code works on plain C pointers
to FileData structs, which may point at freed memory. With unref calls
spread through-out the code and g_lists of ptrs in some places, that
simply bears the risk that unref and g_list remove can get out of sync.
Additionally, the FileData unref method is questionable already (not just
due to its fd->magick checking and special handling of child nodes), since
for example it does
fd->ref--;
if (fd->ref == 0)
{
/* decide whether to file_data_free() or return earlier */
}
return;
and hence doesn't cover the case that ref<0, and the responsibility to
drop ptrs to freed FileData from any lists or locals, is not within this
method.
------------------------------------------------------------------------------
WhatsUp Gold - Download Free Network Management Software
The most intuitive, comprehensive, and cost-effective network
management toolset available today. Delivers lowest initial
acquisition cost and overall TCO of any competing solution.
http://p.sf.net/sfu/whatsupgold-sd
_______________________________________________
Geeqie-devel mailing list
Geeqie-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geeqie-devel
