[DGD] preserving vars after lib recompile

[bart at wotf.org]

On Wed, 17 Sep 2008 20:42:26 +0200, Petter Nyström wrote
> On Wed, Sep 17, 2008 at 8:01 PM,  <bart at wotf.org> wrote:
> 
> > But indeed, destructing the 'in between' libraries yourself is not needed, the
> > driver will call the driver object for those, which will do the actual
> > destruction. In other words, you only have to worry about the end nodes of the
> > graph (the library you changed on one end, all the objects that (in)directly
> > inherit it on the other end)
> 
> This was news to me.
> 
> Just to get you straight here, if we have three objects: A, B and C. 
> A inherits B, and B inherits C. I change the code of C. Then I only need
> to destruct C and recompile A to get the updated functionality of C 
> in both A and B? I don't have to touch B? (Other than using it to track
> down A as an ancestor of C.) Is this right?

You destruct C, then recompile A.

When you recompile A, DGD calls the function recompile() in the driver object
for anything that depends on C and is needed by A.

This function should take care of destructing the object it gets passed as an
argument, and do any administrative things that need to happen.

The following sniplet comes from my driver object, the kernel lib contains
something pretty similar, this is where B will get destructed.

static void recompile(object obj)
{
    if(inform_compile) {
        catch(inform_compile->inform_recompile_inherit(obj));
    }
    destruct_object(obj);
}


So as long as you use klib, or ensure your driver object does something sane
here, you don't have to worry about B in this case.

Your objectd still needs to keep track of B of course, if only to be able to
deal with you changing and recompiling it ;)

One thing to keep in mind is that you have to take care of the end nodes,
which in some cases could be libraries instead of objects, consider this:

C is inherited by B, which was inherited by A, however, A has been destructed.
This leaves B in memory.

Your upgrade system shouldn't try to compile A in this case, it should
destruct B (and then compile it if you want to leave things exactly as they were)

If you don't do this, an old issue of A will be kept as well until something
tries to inherit B and cause recompile(B) to be called in the driver object,
which will destruct B and free the old instance of A.

While it is possible to run with different issues of the same library, this is
something you should really only allow in very exceptional cases, it is bound
to bite you, esp. if you also consider using the precompiler.

I'm not using klib, and trying to build a working system from scratch for this
is not entirely trivial from my experience, and mistakes can cause you a lot
of work, in my case, including figuring out how I was gonna analyse and maybe
change a statedump to figure out which objects I had lost track of. The cause
of my problem there turned out to be a library that once existed, was still
loaded, but didn't have a corresponding .c file anymore, and for which the
objectd information had been lost.

Since then I rewrote my code from scratch and added a bunch of tools to
inspect the data of the object daemon and to locate libraries of which more
then one issue exists.

Doing this based on klib and the objectd examples out there shouldn't be too
difficult tho since all the hooks you need are already there. In that using
klib will make quite a difference :)

Bart.
--
Created with Open WebMail at http://www.bartsplace.net/
Read my weblog at http://soapbox.bartsplace.net/