------art_39358_13635961.1180221200365
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

 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.

------art_39358_13635961.1180221200365--