[MUD-Dev] Re: atomic functions

[Felix A. Croes]

Shawn Halpenny <malachai at iname.com> wrote:

> On Wed, May 06, 1998 at 09:34:27PM +0200, Felix A. Croes wrote:
>[...]
> > In my design, events are only cancelled if they fail to commit their
> > changes.  Uncaught errors cause the event to terminate, but do not
> > make it skip the commit phase.
>
> I do not understand how that can work.  A careless builder who forgets a
> range check on some value could corrupt objects and the results are not
> easily traceable.  Perhaps I'm using a different definition of "error"?
> Simplistic example:
>
> function SetMaxDamage(n)
> {
> 	if (n < 0)
> 		throw out_of_range
>
> 	max_damage = n
> }
>
> SetMaxDamage(-1) is called in context of an event.  The exception is what I
> term an error:  throw out all local data and forget this event.  There is
> no other clause to catch that exception and recovery is not possible, so it
> must terminate the event.  Letting it continue on and commit changes, let
> alone schedule other events because it is allowed to commit, isn't
> acceptable.

Letting it continue executing is certainly unacceptable.  Letting it
abort on the error and commit changes made before the error occurred
may still be unacceptable from your point of view, but is okay for
me.  It works for a large number of muds, including all those using
LPC, ColdC or MOO.

Nevertheless, forgetting changes made if an error occurs can be
useful, and that is where atomic functions come in.


>[...]
> > I contest this :)  I claim that it is very useful indeed, and not
> > at all illusionary.  I frequently find that actions which have to
> > be atomic -- for instance, moving a hungry dragon into a room,
> > which changes both the environment of the dragon and the inventory
> > of the room -- are part of a larger event, the actions of which
> > I want to be executed precisely in that other without other
> > events intervening.
>
> Moving the hungry dragon into the room does not have to be an atomic
> action.  Removing the dragon from its current room is one event, putting it
> into the next room is another.

You have broken up the event into smaller ones, but for my argument
it does not matter -- removing a dragon from a room still requires
changes to both the dragon (new environment) and the room (dragon
removed from inventory).  If the event fails halfway, the
inventory hierarchy has become inconsistent.  Making the movement
part of the event atomic prevents this.


> This is an attempt to minimize the number
> of C&C collisions if you have a lot of these things going on (get rid of the
> container-room ideology and this is even less a factor--something I'll
> probably end up going with).  The movement events will be executed in the
> correct order, since the dragon removal event posts the dragon insertion
> event only if it successfully C&C's.

But breaking up the event into smaller ones, even though these are
executed in the proper sequence, does not help meeting the other
requirement: that no other events intervene.

Felix Croes

--
MUD-Dev: Advancing an unrealised future.