Robert Klemme wrote:

>"Charles Hixson" <charleshixsn / earthlink.net> schrieb im Newsbeitrag
>news:41408EA1.9030204 / earthlink.net...
>
>  
>
>>What's being done here is updating a database (an Sqlite database
>>actually).  So what I want to do is accumulate a bunch of changes, and
>>then periodically add them either when things would be idle or when the
>>number of changes starts to use too much ram.  But I don't want to loose
>>them when the program terminates, and the class doesn't terminate itself
>>(notice that the table is referred to, indirectly, via a class variable
>>@@wtable).  Now the data accumulation happens in a class separate from
>>the class that manipulates the database table, etc.
>>
>>The stream.sync approach doesn't seem to apply here at all.  (Note that
>>I want to be flushing data in a Hash Table to the file...so I can't use
>>any automatic file flushing.)
>>    
>>
>
>I don't know how big your hash will grow, but did you try to just marshal
>the hash like this after every change you want to preserve.  Marshal is
>quite fast, so it might be worth a try:
>
>File.open("storage", "wb"){|io| Marshal.dump( hash, io )}
>hash = File.open("storage", "b"){|io| Marshal.load(io)}
>
>  
>
>>The suggestion of the END block of the file is a plausible approach,
>>which I had forgotten existed.  What I really want is a class finalizer,
>>    
>>
>
>As mentioned ruby seems to flush all open handles on exit.
>
>  
>
>>but lacking that I should be able to make the END block work, with a bit
>>of redesign.  It will drastically decrease the portability of the class,
>>but as each file can have it's own END block, it shouldn't decrease the
>>portability of the file.
>>    
>>
>
>If you want to save for safety reasons (i.e. to avoid data loss on a crash
>of the Ruby interpreter) you must flush after every write anyway.  So
>there would be no need for END block or whatever other means.
>
>Kind regards
>
>    robert
>

Marshall is the wrong answer.  The hash will be limited to around 1500 
items by flushing.  The database of which it is a partial updated mirror 
will likely grow to around 5,000,000 items.  The flushing process 
detects all dirty items in the hash and passes them to another routine 
which either updates an existing item or adds a new one.

Actually, there will likely be several (?) hash tables simultaneously in 
the eventual implementation, and each one will need to implement a 
different version of this procedure.  Fortunately, the records 
structures are both orderly and consistent, so I won't need the kind of 
flexibility that marshall implies.  I may even eventually translate this 
into a compileable language after I get everything working, for the 
increase in speed that's available.  (My plan is 1) first get it 
working, 2) second, speed it up.)  If this is adopted I'll probably use 
D (DMD), as that seems the best of the current compileable languages.  
(I wonder if Ruby-inline could handle D code?  Well, no rush.  That's a 
long ways off yet.)