[MUD-Dev] Re: optimizing code

[Chris Gray]

[Hans-Henrik Staerfeldt replying to <diablo at best.com>:]

 >The way to do this is to implement an 'event queue'. The queue is a sorted
 >list of whan what is going to happend. So you peek at the first element,
 >and notice that it need activation at time x, then wait (sleep) for x-now
 >timeslices and then start the event at the top of the queue (might be
 >a mobile moving, or parsing of one players commands). If the event is
 >to be recurring regularly, insert a new event in the list at the time
 >the event is to recur .. as simple as that.
 >
 >If a mobile has two timers, it should have two event in the queue.
 >We have used this system extremely successfully in Valhalla where the
 >event queue is the very core of the engine (along with messages)
 >to handle unlimited number of co-routines to be attached to each
 >object.

Agreement here. This sort of question has come up a couple of times
over the years, and I think it comes down to how your MUD is structured.
Mine is completely single-threaded - it isn't linked with a threading
library. So, I have a sorted list of events (sorted by expiry time)
like Hans-Henrik describes. My way of waiting for the time to the
earliest event to expire is to put that time into the main 'select'
call on the connection and client sockets. Since all new events will
be created either by user action or an internal event from the timer
queue, I know that the select is not active when any new event is added
to the queue. (It was a bit more compicated on the Amiga, where I had
to cancel a too-long timer and restart it at the desired interval.)

A couple of refinements to this can be done. One is that the MUD is
there to service players, not its internal workings. So, I put a limit
on how many timer events I would service before going back to check
for client socket activity by just doing the select with a 0 timeout -
no need for special code.

Also, whatever wakeup mechanism is used (select in this discussion) isn't
guaranteed to wakeup right on time - it may be a bit late. So, after the
wakeup and servicing of sockets, I find the current time, and run
through the event list doing events scheduled for any time before the
current time (subject to the above-mentioned event limit).

My mobiles ("machines" in my terminology) normally only have one event
each. When that goes off, they do whatever they need to do, and end the
event processing by scheduling the next one. Having two separate events
might complicate the code in those events, if they have any possibilities
of interacting.

[P.S. No need to be formal about names - Chris G. works fine. The 'G.'
being needed since there are at least 2 active Chris's on the list.
Although the other seems to go by JC or JCL.]

--
Don't design inefficiency in - it'll happen in the implementation. - me

Chris Gray     cg at ami-cg.GraySage.Edmonton.AB.CA
               http://www.GraySage.Edmonton.AB.CA/cg/