[DGD] A deadlock with inheritance or call_other

[Robert Forshaw]

This is a problem I encountered a while ago in coding my mudlib, and didn't 
think to question my solution until now. There is only one thing that I find 
unsatisfactory with the way I'm currently doing it, and I am wondering if 
there is a more experienced coder out there who can offer a better solution.

The problem I am speaking of is when the compiling or cloning of an object 
demands the prior compilation of another object. That latter object in turn 
desires the prior compiling of the first object. For example, I have my 
object daemon and that object daemon makes use of a "node_mapping" 
lightweight object. However, the creation of any object demands that the 
object daemon exist to do its part of the job. The result then upon the 
compiling of any object is a deadlock, as the object daemon demands the 
existance of "node_mapping" in its initiation, and vice versa, the node 
mapping wants the object daemon to exist upon its compiling.

My workaround for this is to create an include file listing the pathnames of 
any object I need to have precompiled (precompiled meaning - unconditional 
compiling by calling the original kfun "compile_object", rather than the 
afun) from the driver, and have the driver traverse this list, compiling 
each in turn, so as to circumvent any demands on the regular compiling of an 
object as dictated by my afuns.

Except there is problem with this - I have a program manager that stores 
away each edition of a program as it is newly updated and compiled, so as to 
allow for the restoration of earlier copies of a program. But since, during 
the compiling process I describe in the above paragraph,  I'm calling the 
original kfun, this process never actually occurs (the relevent program 
manager function is called from the afun of compile_object). This means 
compiling the list of objects once again, this time from a seperate file 
"initialize.c" so as to be calling the afun rather than the kfun. My 
"initialize" function has ended up looking something similar to this:

static void initialize() {

    compile_object(OBJECTD);
    compile_object(PROGD);
    compile_object(FILED);

    i = compile_object("/system/init");
    i -> init();
    destruct_object(find_object("/system/init"));
}

And the contents of the "init" function is just a repetition of the first 
three lines of the "initialize" function.

I find this solution to be very ugly, and any suggestions on this problem 
are most appreciated.

_________________________________________________________________
Want to block unwanted pop-ups? Download the free MSN Toolbar now!  
http://toolbar.msn.co.uk/