Tracking DRbObject References?


#1

Hi,

Does anyone know of any work done on keeping track of the number of
the existing DRbObject references to a local object?

It seems that if I can keep track of the propogation of DRbObjects
(adding calls to a service on the server where the local server that
update the distributed reference count), that it should be sort of
trivial to release the local object only when all distributed
references are gone.

On #ruby-lang it was suggested that this might be premature
optimization, however, I am sure that this will be necessary. The
purpose of the system I am writing is to provide a framework for Actor
computation. One of the programming techniques in the Actor model is
to produce a large number of worker actors on a machine with many
processors for the express purpose of computing a small part of a much
larger computation. However, another technique is to create a smaller
number of actors that you will keep around and possibly propogate
those references to other actors in the system. So you can see how
the distributed system could easily become littered with
undiscoverable objects that would sit around wasting resources if they
aren’t garbage collected, yet we can’t necessarily toss them away
right after we use them.

If there’s anything that you think might be helpful, I’d be very
appreciative.

Thanks,

-Dan Nugent

Don’t Feel Like Typing? Send me a voicemail:
http://odeo.com/sendmeamessage/DanNugent


#2

On Mar 27, 2006, at 5:27 PM, Daniel N. wrote:

Does anyone know of any work done on keeping track of the number of
the existing DRbObject references to a local object?

IdConv would be the thing that does this.

It seems that if I can keep track of the propogation of DRbObjects
(adding calls to a service on the server where the local server that
update the distributed reference count), that it should be sort of
trivial to release the local object only when all distributed
references are gone.

On #ruby-lang it was suggested that this might be premature
optimization, however, I am sure that this will be necessary.

!!!BIG, RED WARNING FLAG!!!

Program based on necessity, not on inferred necessity!

aren’t garbage collected, yet we can’t necessarily toss them away
right after we use them.

If there’s anything that you think might be helpful, I’d be very
appreciative.

There are two better options for tracking distributed objects.

Switching to a different IdConv like NamedIdConv.

Using a TupleSpace to manage the distributed objects in your system.


Eric H. - removed_email_address@domain.invalid - http://blog.segment7.net
This implementation is HODEL-HASH-9600 compliant

http://trackmap.robotcoop.com