From: James Tucker <jftucker@...>
Date: 2007-05-27T15:12:13+09:00
Subject: Re: querying persistent ruby objects in memory

Someone else was talking about this kind of problem the other day in 
#ruby-lang.

Another posted an elegant solution to the problem (which incidentally 
was refused as it was another process), however:

#!ruby
raise 'You need to install win32/process' unless require 'win32/process' 
if RUBY_PLATFORM.include? 'mswin32'
# parent forks off and dies, leaving child as daemon
exit 0 if !fork.nil?

# daemon code starts here
require 'drb/drb'
require 'thread'
require 'server'

$SAFE = 1    # disable eval() and friends

DRb.start_service("druby://:2020", Server.new)
puts DRb.uri
DRb.thread.join


Francis Cianfrocca wrote:
> On 5/26/07, braver <deliverable@gmail.com> wrote:
>>
>> On May 26, 2:24 pm, Robert Klemme <shortcut...@googlemail.com> wrote:
>> > I'd consider using Marshal.
>>
>> That's just plain serialization, isn't it?  I've seen that and
>> Madelaine; but my wish is to keep the objects in memory without the
>> need to dump/reload it, however fast.  (That would be a last resort.)
>>
>> The question is, can we keep an object in memory in one thread, and
>> explore/change it from another?  In the worst case, we can probably
>> quickly dump an object into a memory region and reload it back via
>> Marshal -- I guess a crude solution is forming here, using shared
>> memory or RAM disk -- have to see what's there for macs...  But still
>> I wonder what folks think in terms of all kinds of RAM persistence in
>> ruby solutions.
>
>
>
>
> Aren't you overengineering a little? You want to amortize a ten-second
> startup cost over a (presumably) large number of operations against some
> dataset. But you keep talking about threads. That tells me that your 
> process
> will run for a long time and will know all the operations it has to 
> execute
> upfront. In that case, forget about threads and just serialize your
> operations. Your life will be much simpler.
>
> But on the other hand, you talk about shared memory and about not 
> wanting to
> write a client/server application. That suggests that you're thinking of
> keeping this dataset around and having other PROCESSES sent requests 
> to it
> at arbitrary times. In that case, don't use threads either, or 
> shared-memory
> for that matter. Life is too short to debug all that stuff. Write 
> yourself a
> little client-server application and be done with it. If you don't 
> want to
> deal with the network programming, use EventMachine.
>