[Prev][Next][Index][Thread]

# Re: Server Code

- Date: Sun, 2 Jun 1996 08:08:00 PDT
- From:
- Cc: MOO-COWS <moo-cows@parc.xerox.com>
- In-reply-to: bartmoss@mistral.co.uk's message of "Sat, 01 Jun 1996 03:20:16 PDT" <Pine.LNX.3.91.960601101809.306A-100000@ralin.mistral.co.uk>

    bartmoss writes:
    > I'm calling verbs from server calls, similar to how :enterfunc gets
    > called everytime a player enters a room.
    > The functions is called 'call_verb', and it returns a error type. But I
    > would like to know what the return of the verb that was called is after
    > it finishes executing so that the code in the server can react to it.

    Here's a message I sent earlier to this list about how this part of the server
    works.  It doesn't quite hold your hand through the process, but it should give
    you enough information that, when you *relook* at bf_move(), you should be able
    to notice more of the structure of that function.
    -------------------------------------------------------------------------------
    Date:	Wed, 20 Mar 1996 18:01:25 -0800
    From:	Pavel Curtis <pavel@parc.xerox.com>
    Subject: Calling verbs from built-in functions

    > I have indeed studied on create() which does the following:
    >	call_verb(oid, "initialize", args, 0);
    > I found it an easy hack, and after some testing it did work.

    It's not that this call is wrong, it's that you're wrong in assuming that it's
    this call that makes the server actually invoke the "initialize" verb.  Take a
    look further at bf_create() and note that it returns
    	make_call_pack(2, data)
    Note also that it tests the value of the C argument `next' in deciding what to
    do.

    The point is that built-in function implementations which call verbs are
    actually called *twice*.  The first time, they do some work, call `call_verb()'
    to tell the virtual machine which verb to call, and then return
    `make_call_pack()'.  The virtual machine notices the `make_call_pack()' result
    and saves away the arguments to `make_call_pack()' for later use.  It *then*
    calls the verb mentioned in `call_verb()'.  When that verb returns, the virtual
    machine calls the built-in function implementation *again*, passing the first
    argument to `make_call_pack()' as the argument `next', the second argument
    to `make_call_pack()' as the argument `vdata', and the result of the verb call
    as the argument `arglist'.  The built-in function can then do as it likes,
    either returning normally this time, or raising an error, or even calling
    another verb; in all cases, its intent is communicated to the virtual machine
    through the kind of `package' it returns.

    What your code does is to mix up its signals.  On the one hand, it called
    `call_verb()' to set things up for a verb call; on the other hand, it returned
    `no_var_pack()' (which is equivalent to `make_var_pack(zero)').  So part of the
    virtual machine is set up to call a new verb while the rest is taking this zero
    you returned and pushing it on the stack.  The virtual machine, in executing
    the code for that verb, will never notice that there's this extra value on the
    stack.  The problem is that the MOO-code compiler actually keeps very close
    track of exactly how big a stack is necessary, and the virtual machine only
    allocates precisely enough, with no extra.  That extra value you got pushed on
    is taking up space that was supposed to be used by the verb's code.  The result
    is that the verb may very well try to use more stack slots than exist, thereby
    overwriting some random piece of memory.

    In your testing, you got lucky and that overwriting didn't cause a crash and
    (apparently, but not certainly) didn't destroy any other useful data.  It could
    have done either or both.  *That's* why I advised people not to use your code.

    I've Cc'd MOO-Cows on this response because this is a tricky part of the way
    the server is implemented and it's not explicitly documented anywhere, so lots
    of folks are likely to get it wrong.  Perhaps, with this message, more folks
    will either get it right or know enough to stay away from the area completely.

    	Pavel
    -------------------------------------------------------------------------------

References:

- Server Code

- From: bartmoss@mistral.co.uk

- Prev: Re: Server Code
- Next: time() built-in
- Index: MOO-cows
- Thread: MOO-cows

Home | Subject Index | Thread Index