housekeeping datastructures [was Re: Breaking up shapefiles Re: [Xastir] ESRI shapefiles and dbfawk]

Tom Russo russo at bogodyn.org
Sun Dec 19 15:40:14 EST 2004


On Sun, Dec 19, 2004 at 10:43:20AM -0800, we recorded a bogon-computron collision of the <archer at eskimo.com> flavor, containing:
> On Sun, 19 Dec 2004, Tom Russo wrote:
> 
> > The "RTree" data structures used to do the spatial indexing are permanent ---
> > once a shapefile is loaded, its index sticks around until you shut down
> > the program.
> 
> I expect that many people run Xastir for short periods of time, or
> perhaps a few days at a time.  Others run it for extended periods.
> I have no idea what the ratio is between these two sets of users,
> but if the rtree structs stay around, that could hurt the
> long-running group.

I'm in the long-running group.  Uptime typically a week or more, and only
that short because I update the code from time to time and have to exit
to do the new make install.

> If there were an easy way to add an access timestamp for the rtree,
> perhaps one could waste that rtree or section of an retree if it
> wasn't accessed within the last XX days?  Not sure if that's
> practical with the current code though.  You tell me.

I think it would not only be practical, but trivial.  As long as there's 
some way to run a periodic cleanup operation (say once an hour).  

The current code keeps a private data structure for each shapefile found,
and stores that data structure in a hash table.
I tried to write it so that the implementation details were somewhat
insulated from the map_shp code --- all map_shp cares is that the structure
contains an element called root that has the pointer needed to pass to
the rtree library.  At the moment, the "shpinfo" structure contains only the 
filename and root of the RTree for that shapefile.  It could trivially be 
extended to have a timestamp of last access.  A periodic cleanup routine 
would then only need to run through the hash of shpinfo data, check 
timestamps, and do a recursive destruction of the structure and remove it 
from the hash table if the last.   

I would just need to write a safe destructor for a single shpinfo item
(which would pretty much mean nothing more than migrating 6 lines of code 
from destroy_shp_hash to a separate routine), write a short routine to 
scan the hash table for stale entries and kill them, and get it called 
every so often.  Make a slider in the "timing" dialog to set the period
for purging them, and the job's done. 

Hmmmm.  A bit tied up for the next few hours, but I have some dead time
coming up.  I'll see if I can explore this.

-- 
Tom Russo    KM5VY     SAR502  DM64ux         http://www.swcp.com/~russo/
Tijeras, NM  QRPL#1592 K2#398  SOC#236 AHTB#1 http://www.qsl.net/~km5vy/
 "When life gives you lemons, find someone with a paper cut."



More information about the Xastir mailing list