Ok, I've been thinking about this while in my Operating Systems class
bored out of my mind. The problem with trying to save every event that
happens so that you can restore the mud to the same point after a
crash/reboot is that it will be slow. The processor speed doesn't make any
difference because the program has to stop and wait for the data to be
written out to the hard drive, and hard drives are very slow.
Tony's solution is pretty good, and would solve several stability
problems and make saving all those events pretty much unnessesary. However I
doubt many imps are willing to go out and buy several machines just to run a
free mud, in fact the imp on my current mud didn't want to buy more ram so
that we could run our overworld maps.
I've been thinking that it might be better to have a separate program
that runs along with the mud and does all the actual saving to disk. For
instance, the mud starts up, then creates a child process (or thread if C
supports threads?) called Shakespear. Whenever something on the mud happens
that would normally be written to disk the mud sends the data to Shakespear,
who takes care of actually writing it to disk. This way the mud server
doesn't have to wait for the hard drive, it just passes it onto another
program which will eventually save the data.
There may be some things I haven't thought of which can go wrong, but
this would be a fairly simple program, and could pass a message back to the
mud if anything went wrong which would cause the mud to try and handle it by
itself. And it would allow for a lot of data to be constantly written
without really slowing the mudserver down.
Mike
+------------------------------------------------------------+
| Ensure that you have read the CircleMUD Mailing List FAQ: |
| http://qsilver.queensu.ca/~fletchra/Circle/list-faq.html |
+------------------------------------------------------------+
This archive was generated by hypermail 2b30 : 04/10/01 PDT