[MUD-Dev] Re: atomic functions

[Felix A. Croes]

Jon A. Lambert <jlsysinc at ix.netcom.com> wrote:

> On  3 May 98 at 1:23, Felix A. Croes wrote:
> > Jon A. Lambert <jlsysinc at ix.netcom.com> wrote:
>[...]
> > > Thus an Event may be made up of many methods/functions, all of which must
> > > succeed for the event to commit.  Methods may schedule additional Events 
> > > and these events will be scheduled regardless of whether the generating
> > > Event succeeds or not.  So in many cases, Event calls will be obviously 
> > > be placed just before the successful return of the top-most method.  
> > > There is a caveat.  A method/function which is called as an event 
> > > should ensure that it checks the state of the caller/callee for state 
> > > validity.  Nothing comes for free.  I have just shuffled the complexity 
> > > into another area of program design.  I have a theory this might be 
> > > unavoidable.  :(
> > 
> > Hmm.  That is one thing I mean to do differently: if the current
> > event fails to commit, then any events generated by it are unscheduled.
>
> Currently I have no way to do this.  

In your system, isn't it also necessary to check the state of successor
events?  For example: event A schedules event B, and then fails.  Event
B is started and succeeds.  Event A is restarted, schedules event B
again, and succeeds.  Event B is started and succeeds.  Now event A has
completed once, but successor event B has completed twice, even though
B can only be scheduled by A.

Also, doesn't this imply that when A schedules B, it cannot pass along
data to B?  After all, that data has been prepared by an event that may
turn out not to have existed.

This looks like a very chaotic system to me.  What are the advantages
that make you prefer it?

Felix Croes

--
MUD-Dev: Advancing an unrealised future.