[MUD-Dev] C&C and Event Rescheduling

[Shawn Halpenny]

Chris Gray wrote:
> 
> [Shawn H:]
> :For the record, object methods appear the same to the DB as object
> :attributes.  This makes changing a method the same as changing an
> :attribute--the C&C mechanism will take care of the contention where
> :Bubba is opening a door and Boffo is changing the code for opening
> :the door.  Only the VM cares if the contents of an attribute actually
> :represent an attribute or a method.  None of this is gospel in my
> :design yet, so I fully expect you to blast some holes in it :>
> 
> Is it really necessary to be this careful with code changes? To me, the
> are outside of the scenario, in that they are not directly visible to
> players, or to NPC's, etc. So, it doesn't really matter when code
> changes actually take place. 

Actually, I plan to not be careful with code changes at all.  They'll
compete for a clean run-through with that door just like the rest of
the events.  The thing that nags at me is that door-opening events
that have already begun executing, but can't commit yet, because
Bubba's changing the door code, are restarted.  That's all good and
fine, but I wonder if they should have executed with the old door
code since that was the expectation when they ripened.  Otherwise, it
comes out such that changing the code while doors are being opened
results in those doors who have already tried to open (but couldn't
because the code change caused their death and reschedule), now
opening differently (i.e. different functionality in the code).

I suppose it should probably be looked at from the perspective of the
player opening the door.  She has no idea that that door-open event
is being killed and rescheduled, so the code change effectively looks
like it took place before she opened the door since she'll have no
indication of what is going on until the event dumps some output back
to her.  This seems the correct behavior to me, but I'm wondering if
it should be that way for all cases?  If not, is the worst thing that
could happen something "logically interesting" like that chest
example a few posts back?

>                              If an administrator is doing code changes
> on a running system, it seems the desire is for those changes to take
> effect "whenever they get there", otherwise that administrator would
> have to take great care to put manual flags around everything, to block
> out uses while the changes are being made. Often, changes to code will
> need changes to more than one piece of code - do you want to add
> provisions for manual locking?

I sure don't, hence allowing methods to look like attributes to the DB.
Things will compete nicely and (if what I planned above holds true in the
necessary cases) the new code will indeed drop into place whenever it gets
there (i.e. when it gets a clean run through with its object--should be
easy, since all it is doing is writing to it).  A bonus is that any events
whose processing called a method that was replaced are killed and
rescheduled by the same mechanism already in place for attributes.

> For the record, when a wizard edits a piece of code in AmigaMUD, as
> soon as the edited code is accepted by the server it becomes the one
> official copy of that code, and further uses will use it. I've made
> no provisions for delaying that switchover. Then again, my server is
> single-threaded, but all the discussion of multi-threaded execution
> didn't trigger any thoughts about protecting code changes.

There is only ever one piece of executable code in place for the methods
being changed.  All object updates are atomic, and all methods execute with
their own little VM in their own thread, so there's no ugly stack magic
going on.  The DB should just merrily commit things when they're ready and
everyone will be happy, regardless of what's being changed when or where.

--
Shawn Halpenny

"At any given time there is a 50% chance I've become discontinuous
 on the probability axis."
                                            - Me