Reason for not allowing import twice but allowing reload()

Chris Angelico rosuav at gmail.com
Tue Mar 1 19:13:23 EST 2016


On Wed, Mar 2, 2016 at 9:29 AM, Ian Kelly <ian.g.kelly at gmail.com> wrote:
> I certainly understand the value of being able to work on a mudlib
> without having to restart the mud. There's a big difference between
> that and clocking a year of uptime just because you can, though.

Oh, sure. I mentioned the year because I have done that once or twice,
but it's the week, rather than the year, that's truly important. If
something came up that meant I absolutely had to reset everything on a
six-monthly basis, no big deal (although I'd rather not have a reset
every month).

> The MUD that I used to play had scheduled restarts every 2-4 weeks,
> not to perform updates, but just to restart the process and clear out
> memory leaks. This never caused any real problem. You knew that it was
> coming because it was announced, and you took a break for a couple of
> minutes. If you were AFK, then your auto-login script reconnected you
> within shortly after the MUD came back up.

Yeah, and I play one that has semi-scheduled restarts about every 6-10
weeks, for similar reasons (and also for game balance reasons; they
deliberately don't save gear across restarts, so people have to gather
new gear). I haven't had issues with memory leaks on my server, but
it's relatively low traffic. Again, though, if it turned out (under
heavier load) that periodic restarts were important, I could design
around that requirement, but there's no way I could design around a
model of "weekly downtime as the only way to change anything", the way
games like Magic: The Gathering Online do. I've once seen them have to
do an emergency out-of-band patch - and it took them an hour or
something of outage to do it. Unacceptable in my book.

ChrisA



More information about the Python-list mailing list