Reason for not allowing import twice but allowing reload()

[Ian Kelly]

On Tue, Mar 1, 2016 at 3:02 PM, Chris Angelico <rosuav at gmail.com> wrote:
> On Wed, Mar 2, 2016 at 8:53 AM, Ian Kelly <ian.g.kelly at gmail.com> wrote:
>> I have a hard time understanding the appeal of super-long uptimes. I'm not
>> even comfortable running a single kernel version that long. What's so awful
>> about 5 minutes of announced downtime in the middle of the night once a
>> month while the system restarts?
>
> It kicks connections off, which may not matter to web sites, but it
> matters to servers that are designed for long-running connections. But
> more importantly, five minutes once a month isn't enough to do all
> your updates - so a live-update system would be required even with a
> regular monthly reset. I tend to have announced outages for kernel
> updates and such (eg a couple weeks ago), but in between, I want to be
> able to keep everything going, even though I'm making changes.
>
> Maybe I don't get to a year all that often (from memory, I think I've
> just twice achieved >1y uptime), but I certainly have multi-day
> uptimes, despite making changes multiple times a day. And I want to be
> able to deploy changes in the middle of a game, not leave off until
> the next scheduled downtime. So, yes, I need to be able to modify an
> already-imported module.

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.

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.