From: Charles Hixson <charleshixsn@...>
Date: 2004-09-11T08:06:59+09:00
Subject: Re: Problem with ensuring consistency .. Finalization??

Robert Klemme wrote:

>"Charles Hixson" <charleshixsn@earthlink.net> schrieb im Newsbeitrag
>news:41417F73.5060002@earthlink.net...
>
>  
>
>>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.
>>    
>>
>
>So if I understand you correctly it's like this: you have a hash data
>structure in mem that keeps some data among that data that is not yet
>present in the DB.  You want to store all dirty data in a file to make
>sure that in case of a crash you don't loose anything.  From time to time
>you write the dirty stuff into the database and if that succeeds you clear
>the temp disk storage.  I'll attach something that shows how I image this
>could work.
>  
>
Sort of.  The disk storage is permanent, it's the hash that's 
temporary.    I certainly wouldn't want to eat up my ram by holding the 
entire database in ram, when at any one time it didn't need most of it.  
OTOH, a persistent hash would be a reasonable answer...well, I haven't 
looked at your code yet, so I shouldn't comment.  It sounds like it 
would be a reasonable answer.  I haven't been planning to persist the 
hash itself, but if I can, without excessive cycle use, then that would 
just by itself solve the current problem.  (OTOH, it also looks like
...
    at_exit    {  flush  }      #   this is run after the files are 
opened and the hash is initialized
  end  #  initializer
...
end  #  class

will solve the problem.   I've read the description of what it does 
three times, and I still can't be *sure* that the file and class 
variables will still be extant when I run it, but it looks like that's 
the intent.


>>....  (My plan is 1) first get it
>>working, 2) second, speed it up.)
>>    
>>
>
>That's the way how it should be ("premature optimization..."). :-)
>
>  
>
>> 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.)
>>    
>>
>
>Just a wild idea:
>
>functor = D::compile <<EOF
>  D code here
>EOF
>
>functor.call( "foo", "bar" )
>
>Of course you'd have to compile the code into a shared lib and dynamically
>load it.  But it sounds feasible IMHO.  Maybe it's a good idea to provide
>a framework for this, so integration of other languages becomes easier.
>
>Kind regards
>
>    robert
>  
>
Thanks for your assistance.