[MUD-Dev] C&C and Event Rescheduling

[clawrenc at cup.hp.com]

In <9708120437.8b94 at ami-cg.GraySage.Edmonton.AB.CA>, on 08/12/97 
   at 08:14 AM, cg at ami-cg.GraySage.Edmonton.AB.CA (Chris Gray) said:

>[Chris L:]

>:  Please enters the following very rapidly:
>:
>:    N, S, E, W.

>It seems to me that, even if they are all on the same input line,
>they are separate commands from the user. 

As a general rule, yes.  There are exceptions.  Consider the case:

  > dig panama canal
  You begin digging.
  ...many hours later...
  You are still digging.
  You are attacked by the Orcs!
  > kill orcs
  Sorry, you'll have to wait till you're done digging.
  > oops

A silly implementation to be sure, but it illustrates.  Another:

  > n,n,n,n,n,n,n,n,n,e,e,e,e,e,e
  You go north
  ...
  There an incredibly valuable diamond here.
  You go north.
  You go east.
  You go east.
  ...
  > Go back!  Go back!
  ...
  > l
  There is nothing here.

The summary we arrived at last time was that by default user commands
should be executed strictly sequentially.  This was to be done via
sequence number dependancies.  However, we also saw a use in commands
which were to be explicity executed in parrallel with other user
commands.  One of the primary uses for such was an interrupt command
which more or less said, "kill the entire command queue NOW!".

(Hey Jon!  This is another thread to add your list of things to dig up
-- the one about command sequencing, priority commands, command
interrupts, and job control for asynchronous command execution.  It
was mainly between CG and myself.).

>I'd say that an input
>command from a user cannot even be ready for execution until all
>previous commands from that user have C&C'd. 

In the general case yes.  An explicit exception should be made for
interrupt commands.

>Haven't we talked about just this
>before?

Yup.  However our new members didn't catch that thread.

>:While rooms are an odd example to chose here, try any other command
>:which launches a sequence of operations where each operation is
>:dependant on the one before.

>This suggests to me not that there be anything in the DB to handle
>this, but that their be something in the system to handle it. First,
>I assume that the programmer doing this has checked the correctness
>of the two routines before trying this. If not, then, if that kind of
>online modification is allowed by the administration, all bets are
>off and no-one can complain about anything that happens. If, however,
>there are administrative controls on this sort of thing (not
>something I've thought about yet!), then it behooves the programmer
>to do the change in a way that won't mess things up. The simple
>answer is to have all changes happen in one C&C. I'm not sure of the
>mechanism in your system or others, but in mine, it just means that
>the programmer should make a function that does a set of function
>assignments/updates. Then, a single call to that function does an
>atomic update of all that is involved.

>That may not be possible in a direct-call situation (i.e. where the
>functions in question are called directly by name, rather than by
>being retrieved via pointer from the DB), in which case I would
>suggest some mechanism within the MUD system whereby edits to code
>can be "held back", and then all released in a batch. It's manual,
>sure, but likely only the programmer can properly judge what all
>needs to be updated.

I don't have a direct solution.  I have indirect corrective tools, and
tool features which help programmers aware of the problem to avoid it:

  Given such a created logical inconsistancy, the object(s) in
question can be rolled back thru time to a point to the logical
inconsistancy and restarted from there.

  My in-game editor has the capability to load several objects for
editing, and then commit those objects in one swell foop (single C&C). 
This does not of course handle the circumstance where the problem
object is a child of the edited object.
  
  I allow an object to be locked when it is being edited.  The result
is that it and all children will not allow any methods other than
those related to security and editing to be called on them.  This
isn't really a very good or strong lock, more of an advisory really,
but it tries. -- 
J C Lawrence                           Internet: claw at null.net
(Contractor)                           Internet: coder at ibm.net
---------------(*)               Internet: clawrenc at cup.hp.com
...Honorary Member Clan McFUD -- Teamer's Avenging Monolith...