[DGD]Swap file?

[Erwin Harte]

On Sun, May 27, 2001 at 04:53:02PM +0100, mtaylor wrote:
> Thanks everyone for help with everything so far.
> 
> As you can probably tell we are at that stage when all the little things we
> didn't know about jump us ;)
> 
> We are now getting this error when we log on two people to the Mud at the
> same time:
> 
> Fatal error: cannot create swap file "Macintosh HD:Dawn of Ages:tmp:swap"

I assume the HD exists, does the 'tmp' folder/directory exist?  DGD
will not automatically create it for you.  The only other thing that
comes to mind right now is that the harddisk could be filling up, or
that permissions are set incorrectly for the DGD process to create the
swap file, but I'm not familiar enough with the macintosh to guess.

> Help please :) 
> 
> We are running DGD 1.2 on a Macintosh. We have written our own mudlib from
> scratch so we may be missing things that we need.
> 
> Also with regards to rlimits. I don't really understand about threads and
> wondered if anyone could explain it easily to me. It's all about where we
> need to put rlimit stuff. How do we apply rlimits to the functions we need
> to and which functions do we need to ;)

Simplified, I think you could say that a thread is the series of
function-calls starting with a function that DGD itself called.

If in your code you do call_out("foo", 10), then in about 10 seconds
DGD will start a new thread beginning with the call to function foo()
in this_object(), assuming the object still exists. ;-)

Another thread-start is when DGD receives input from a network
connection and calls receive_message() in the relevant user-object.

So your typical receive_message() function would look like this:

    static void
    receive_message(string str)
    {
	rlimits (MAX_STACK; MAX_TICKS) {
	    /*
	     * Do what you would normally do, parse and execute
	     *  command-functions
	     */
	}
    }

To make sure a function started by a call_out() is wrapped inside such
an rlimits construct, you would have to redefine call_out() in your
auto-object, like this:

    static int
    call_out(string func, int delay, mixed args...)
    {
        return ::call_out("_F_call_out", delay, func, args);
    }

    nomask void
    _F_call_out(string func, mixed *args)
    {
        if (previous_program()) {
	    rlimits (MAX_STACK; MAX_TICKS) {
		call_other(this_object(), func, args...);
	    }
        }
    }

The 'if (previous_program()) {' condition is to make sure the function
cannot be abused by calling it directly, this way it will only call
the given function with the parameters if it's the start of a thread.

If you're thinking of making _F_call_out() a static function, think
again, because that would make it an 'efun' since it's in the auto-
object, and then you cannot call it from a call_out(). :-)

Of course, this means that status(obj)[O_CALLOUTS] will look slightly
differently.

Some other entry points that you may want to protect the same way
receive_message() is protected are open() and close() in user-objects,
depending on trust the executed code 100% to not do anything stupid.

Hope this helps,

Erwin.
-- 
Erwin Harte <harte at xs4all.nl>

List config page:  http://list.imaginary.com/mailman/listinfo/dgd