[DGD] object finding

[Shentino]

ouch...didn't even know that MP would be an issue...thought that if
you could find by name, then finding by integer would be even easier,
since a clone's name has the index number glued at the end of it.

My guess is that it requires read access to the master object table. 
And if another thread were to write to this, then the first thread
which read the table would be rolled back I imagine...not sure but
according to docs on Phant' SF that's what's supposed to happen.  I'm
just making wild guesses as to how the driver works :).

Anyway...:P

> The only real use for find_object(int i) would be to iterate over all
> indices and find all existing objects.  Is that what you want to use
> it for?

Yes, finding all objects with find_object(int) (or, more usefully,
status(int)) would be useful to me in crash situations.

Suppose that objectd goes belly up and I manage to lose all my
information...and suppose that pathologically another piece of code
picked that precise moment to do a statedump and I don't find out
until it's too late to go back to a known good state.  Being able to
rebuild objectd's database from scratch would be exactly the sort of
thing that find_object(int) (or status(int)) would come in handy for.

Now, I could iterate through objregd and find out what's going on, but
I noticed it doesn't keep track of blueprints outside of /usr, or keep
track of libraries (FIXME?).

I could probably shut down and go parsing through a statedump, but
that's a file I'd rather not access without DGD's supervision and I
don't know for the life of me even how it's structured.

On 4/29/06, Felix A. Croes <felix at dworkin.nl> wrote:
> Shentino <shentino at gmail.com> wrote:
>
> > Par you took the words right out of my mouth...an argument signature
> > for find object that takes an integer instead of a string would be
> > just perfect for what I was suggesting.
>
> In DGD/MP, it's not as perfect as it looks.  You cannot just access
> random object table slots, since those might be under the control of
> a different thread and completely off limits.  There also is a problem
> with finding empty object table slots, which essentially works out as
> asserting a non-presence in that slot for the current thread.  Even
> with the aforementioned implementation problem resolved, it would
> work out as an expensive operation.
>
> I am hesitant to add new MP-busting functionality at this point.
>
> The only real use for find_object(int i) would be to iterate over all
> indices and find all existing objects.  Is that what you want to use
> it for?
>
> Regards,
> Dworkin
> __________________________________________
> http://mail.dworkin.nl/mailman/listinfo/dgd
>