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.
Anyway, while I'm at it, why is this approach even popular? 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). Add a form of IPC so that the manager
can handle some of the memory from the Mud, and you can persist a lot of
the data from the Mud over reboot and crashes, synching the manager's data
to Circle's every so often (maybe with a few consistency checks?) means
that you could probably implement a near complete system of persistence,
with some minor things changing, and a minimum of layover for the player
(since data wouldn't be reloaded, our CircleMUD process would just ask the
manager to attach itself to the pre-existing memory).
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. Storing complete memory state is
entirely possible, and, in fact, has been done with mmap() -- search for
ColdStore on Freshmeat. A method such as that could allow the Mud to
reboot or crash and resume seconds later with even pointers perserved
(thus, every last detail of the Mud, at last synch, would be intact).
Shrug. Some thoughts.
-dak
+------------------------------------------------------------+
| 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