Phantasmal Site > DGD > DGD LPC Reference > DGD/MP and Threads

DGD/MP and Multiple Threads

From: dgd@dworkin.nl (Felix A. Croes)
Date: Thu Apr  7 02:02:01 2005
Subject: [DGD] 1.2.102

>  - Forbid having undefined private functions.
>  - Add a list of undefined functions to status(obj).

To clarify: you can have a prototype for a private function, but if so
it must be declared for the same program.  So just

    private void foo();

is wrong, but

    private void foo();

    private void foo()
    {
	/* do the foo thing */
    }

is no problem.

The list of undefined functions is added so that a mudlib can forbid
active use of such objects, and can generate reasonable errormessages.
>From a Java point of view, an object with only prototypes would be an
interface.

The "list" is actually a mapping.  When object obj has no undefined
functions, status(obj)[O_UNDEFINED] is nil.  Otherwise, it is a
mapping of the following format:

    ([ program_name : ({ func1, func2, ... )}, ... ])

Regards,
Dworkin



From: dgd@dworkin.nl (Par Winzell)
Date: Thu Apr  7 21:24:01 2005
Subject: [DGD] 1.2.102

Felix A. Croes wrote:

> The list of undefined functions is added so that a mudlib can forbid
> active use of such objects, and can generate reasonable errormessages.
> From a Java point of view, an object with only prototypes would be an
> interface.
> 
> The "list" is actually a mapping.  When object obj has no undefined
> functions, status(obj)[O_UNDEFINED] is nil.  Otherwise, it is a
> mapping of the following format:
> 
>     ([ program_name : ({ func1, func2, ... )}, ... ])

The mudlib support to provide 'proper' support for abstract functions is
not entirely trivial, and as I just finished (with Dworkin helping me
work through the issues) an implementation for the SkotOS 2.0 codebase,
I thought I'd briefly summarize my findings. This is probably only one
of many possible implementations, especially since I assume the use of
the kernel library.

 - You will want to mask compile_object() in the System level auto
object, if you are not already doing so. You need two separate systems
to check for two separate kinds of unimplemented functions:
    + For concrete objects, use status(obj)[O_DEFINED] and simply report
any unimplemented functions that are either declared in the compiled
program or inherited normally. A concrete object by definition should
not have any undefined functions.
    + The status() function does not report prototypes that were
privately inherited. It is quite common to privately inherit a program
that declares prototypes it expects its inheritor to implement. To catch
cases where the inheritor fails to implement them:
      * Allocate space for a new TLS slot.
      * In your objectd, add code to forbid_inherit(), compile() and
compile_lib() that keeps track of the undefined functions of each
privately inherited program.
      * In your masked compile_object(), initialize the TLS slot with
whatever data you need for the previous step. Remember that compilation
of one program may trigger compilation of many other programs when
creators are run.
      * At the end of compile_object(), go through the datastructure
(which is likely quite large) you collected in the objectd. For each
compiled program:
        $ Figure the master list of privately inherited undefined functions.
        $ From this master list, REMOVE any undefined functions that
were NON-privately inherited. If I inherit a prototype both privately
and non-privately, the private inheritance is irrelevant.
        $ From the rest of the master list, REMOVE any function that is
actually defined by the compiled program. To do this, you will need to
employ function_object(), but:
          = function_object() from the 'outside' fails to detect static
methods and so you need to create some kind of function_exists() relay
in the auto object that performs function_object() on itself
          = function_object() cannot be run on pure programs, because
the kernel library forbids us from getting an object pointer to such a
program; thus we create a temporary object that does very little but
inherit the program we actually want to test, and then call
function_exists() on this program.


Phew. OK, that sounded complicated. I guess it was. But it works! LPC
has matured even further!

Zell