On Mon, Oct 1, 2012 at 1:01 AM, Roy Smith <r...@panix.com> wrote:
> Well, more strictly, what you need is to keep your state somewhere else.
> Doesn't have to be on disk. Could be in memory, if that memory belongs
> to another process (memcache, redis, or any of a number of in-memory
> databases).
Sure. I'll generalize my statement to "Has to be external to the
process". That generally precludes the direct use of complex objects,
requiring some form of serialization or dump format - you can't, for
instance, retain a "socket connection object" across that sort of
reload.
> Why does it have to be a single process? I could imagine some front-end
> process which accepts connections and hands them off to worker
> processes. When you install new code, you could do it in a different
> directory tree, and then signal the front end that new code exists. The
> front end could then {chdir, munge sys.path, whatever} to the root of
> the new tree and keep going. Existing connections stay up with the old
> code, new connections get the new code.
That's also a good model, for situations that can use it. My situation
is a MUD-like system where different clients can affect one another,
so the most logical way to do it is a single process. For instance, we
have a Dungeons and Dragons battle grid that uses a web browser as its
display engine; you go to a particular URL, key in your login details,
and it sends AJAX long polls to the server. Whenever one client moves
a token on the grid, every other client gets notified. I could, of
course, do this across processes, but I'd end up needing a hefty IPC
system; this way, all I need is a lightweight event semaphore that the
threads wait on, and they look at the process's internal structures
(thread-safe, they need only read at that point). I could have done it
in other ways, of course, but this is nice and straightforward.
But this is getting rather off-topic :) For the bulk of usage
patterns, Python's fine. Most languages don't let you reload code on
the fly, and most applications are never going to be bothered by this
miniscule feature lack!
ChrisA
--
http://mail.python.org/mailman/listinfo/python-list
