On 27.05.2007 00:33, braver 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.)

I find that odd.  Keeping something in memory is usually a *solution* 
for some kind of *business requirement* (e.g. to make things fast).  Why 
would you want to keep something in mem if it can be persisted on disk 
really fast?  I don't know the volume of what you need to handle but did 
you actually try out how fast it is?

> The question is, can we keep an object in memory in one thread, and
> explore/change it from another?

Yes, of course.  Easily sharing memory is one (if not *the*) major 
aspect of multithreaded applications.  But reading your other posting I 
am not sure whether you have the proper idea of MT programming.  If you 
only want to do one set of manipulations at a time you do not need 
multiple threads because there is no concurrency involved.

>  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.

As James suggested using DRb is one option.  Then you can decide whether 
to manipulate the object graph in the server process or send it off to 
the client (and probably send it back after doing your changes).  It's 
probably the best solution in your case because you can start arbitrary 
client processes and manipulate state in the server.  But you should 
make sure that access is proper synchronized to cope with multiple 
clients that connect concurrently.

Kind regards

	robert