<Written before>
Ok, I've been thinking about this while in my Operating Systems class
bored out of my mind...
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...
Mike
<My Thoughts>
I've wondered about that too. Yes you can make your MUD threaded. I've
also thought that you could use that "other thread" to write to a faster
secondary hard-drive. If you coupled a quick drive with the threaded code
and a well planned out save scheme you would be set to go and you could do
it all in one machine. However, Buying the extra machinery on a tight
budget and taking all that time to code the thread, etc instead of coding
real, useable things for your MUD would kind of suck. At least in my
opinion. This has to be the best way to go, too bad I don't want to trade
off time for it. I am sure we ALL have this problem. Sigh.
I need four more of me. =)
Anyway, Good idea 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