[MUD-Dev] Re: atomic functions
Felix A. Croes
felix at xs1.simplex.nl
Sun May 3 19:43:41 New Zealand Standard Time 1998
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?
MUD-Dev: Advancing an unrealised future.
More information about the MUD-Dev