Graham Dumpleton
grahamd at dscpl.com.au
Fri Feb 4 21:07:16 EST 2005
On 05/02/2005, at 2:33 AM, Gregory (Grisha) Trubetskoy wrote: > so as you see A is still there. So you're bound to have to restart > your server at some point. IMO the reload mechanism should be > sufficient enough to avoid having to restart httpd all of the time, > but the developer still needs to understand how Python works and > realize that some situation are only solved by a restart. Actually, vampire gets around that as well. It doesn't use the "imp" module and uses execfile() instead. Taking this approach one has greater control as things aren't stored into sys.modules and one can simply load into a new empty module. This does however mean that variables aren't persistent across reloads which is why deleting stuff actually works. As such, if you do want persistent variables, you have to denote explicitly that this is what is desired by supplying a __clone__() method in your module which will transfer such data across to the new module. By making it explicit, it also makes users face the implications of doing reloads. Most users wouldn't realise that a reload will replace a variable that exists in both new and old modules. This can be really bad if it is a database connection pool, as the original copy is done away with, potentially without actually closing the connections off. Thus one can have an ever increase set of database connections as reloads occur, with most be unusable. Making it explicit also means it is likely that some of the threading issues might be dealt with. For example, what happens if a reload occurs while a separate thread is handing a request and is accessing the data that is being reloaded on top off. Unfortunately, all the reasons why Vampire does all these things isn't documented yet, but am slowly working my way towards it. :-) Graham
|