George Greer wrote:
>
> On Thu, 23 Dec 1999, Daniel A. Koepke wrote:
>
> >On Thu, 23 Dec 1999, Chris Gilbert wrote:
> >
> >> A nice extension you might want to do is pickup on the segv signal and
> >> do this kind of reboot and saving only rent files (nothing else as it
> >> all carries a risk) I should probably put up a patch for that.
> >> Probably helps with the rent duplication bug. Works a treat though,
> >> other than you end up with huge log files (Plan to rewrite the logging
> >> system though) At present the last full shutdown reboot was on dec
> >> 16th and it's still logging into syslog (1MB at the moment).
> >
> >Blergh -- the last thing you want is to corrupt the rent file of some guy.
> >A segmentation fault indicates an error in your handling of memory. You
> >should not, and cannot, trust the state of memory after a SIGSEGV, as you
> >can't know what caused the segmentation fault to begin with.
>
> The only way I might trust such a state is to have a checksum field in
> every record. Even then I'd have to have a hellacious startup time to do
> so.
Most the only crahes we see generally don't effect save/rent files (we
did have one that it did) And it was more a spate of when we were
crashing every 10-15 minutes (due to the delights of events accessing
ptrs that didn't exist) Actually what dak said sounds a lot more
sensible. Never crossed my mind to do it that way. Make dealing with
log files easier as the outpout of the mud could be piped throught the
manager, and it pipes it into the files desired...
> >Anyway, while I'm at it, why is this approach even popular?
>
> featuritis.[1]
Crashing every 10 minutes starts to annoy players when they loose their
equip, case of the once in a while that a rent file gets corrupted
against upsetting players (yes they know it's beta but the time spent
sorting out players begins to mount up/get annoying.
> >It'd be fairly trivial to have a manager program that accepts the
> >connections, forks a copy of itself, and execs into CircleMUD. End
> >result? No need to store/recover this stuff from files, the manager
> >program handles everything, and there's very little you have to alter in
> >the main Circle program (i.e., skip socket creation if the manager boots
> >us, since the manager creates the server socket).
>
> This is probably due the our mentality that "it shouldn't crash" versus the
> quality of some code that some people (perhaps inadvertantly) put into the
> MUD. It may also be due to the popularity of a crash bug once it is
> discovered. It'd probably be something nice to do in the future though.
Yep, it's more spates when I add lots of new bits and test them, but
once players get on huge holes start to show...
> >I haven't worked out this model of persistence in my head, which should be
> >fairly obvious to anyone reading this far, as I'm a bit shaky on what, in
> >particular, you would want to do.
>
> Stick it in an SQL database and give each person their own fork()'d server.
> Make the SQL server figure out the locking and consistency issues. :)
I don't know of many mud server providers that allow ppl to have a sql
server or I'd probably consider it.
Cheers,
Chris
+------------------------------------------------------------+
| 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 : 12/15/00 PST