Re: [Python-Dev] regrtest.py mystery
barry@zope.com (Barry A. Warsaw) writes:
Doesn't that make it into a solution in search of a problem? When is unloading useful? I'm not being facetious, I've just never been hit by the need for it. Cheers, M. -- Q: Isn't it okay to just read Slashdot for the links? A: No. Reading Slashdot for the links is like having "just one hit" off the crack pipe. -- http://www.cs.washington.edu/homes/klee/misc/slashdot.html#faq
On 17 Dec 2001, Michael Hudson wrote:
Shared libraries in XlispStat support unloading. But all of the times I've ever used it, I've used it as a 'reload' : usually while debugging shared libs -- it's handy to keep the interpreter window running while you fix and recompile a bug and load it again. The only case I can thing of where I might use it in production code would also be for a reload, where you might have several alternate 'plugin' modules. When you do an unload, references to objects that were in the shared library are replaced by references to a stub that generates an error/exception. ( That stub routine is part of the builtin dynamic load "module" . ) It doesn't involve traceing all the references -- the pointers are unchanged, but the object is changed. I have no idea what 'the Right Thing' for Python would be here -- I'm not quite clear on what you're trying to fix. I'm just volunteering an example. -- Steve Majewski
On Mon, 17 Dec 2001, Steven Majewski wrote:
However, I will add that if I *did* need an unload for anything, I would think the XlispStat semantics: unloading the module immediately and making any dangling references into exceptions, or replacing them with references to a reloaded module, would seem to be more useful than not really unloading it until all of the references are decremented (if ever) and then unloading. I can't think of a case where I would want to unload a module, where I would not want a dangling reference to something in that module to generate an exception. -- Steve
Python doesn't let you replace a reference to an object with something else -- except in special cases (e.g. with explicit weak refs) there's no way to know where references to an object might exist. So that's not a useful idea, alas. --Guido van Rossum (home page: http://www.python.org/~guido/)
On Mon, 17 Dec 2001, Guido van Rossum wrote:
I was too fuzzy in my choice of words. What I meant was not finding and replacing the references, but replacing the object to which all of the 'dangling references' point. But that won't work either: Python objects share the same head, but total size of the object structs are too variable, and I don't know it's possible to make the minimal size object show the required behaviour. But even if that is possible, another problem with implementing it in a Python extension module is that Python objects are not (except for maybe functions and things that drag along a reference to global module namespace) "owned" by their modules in anything like the association between Lisp symbols and their packages: python modules can import other modules or can dynamically add things to their namespaces. We can't just iterate through a module dict and 'zero' out all of the objects there.
So that's not a useful idea, alas.
If the problem was important enough, I think a way could be found around those problems above, but I'm still not sure that module unloading isn't a solution looking for a problem! -- Steve
In general it's impossible. You can't even replace the type pointer with a pointer to a dummy type, because it would leak any objects referenced from the original object, and it would break if the original object lived in a special free list.
Well, there are a bunch of people who want to undo a partial import, and that boils down to about the same thing. --Guido van Rossum (home page: http://www.python.org/~guido/)
On 17 Dec 2001, Michael Hudson wrote:
Shared libraries in XlispStat support unloading. But all of the times I've ever used it, I've used it as a 'reload' : usually while debugging shared libs -- it's handy to keep the interpreter window running while you fix and recompile a bug and load it again. The only case I can thing of where I might use it in production code would also be for a reload, where you might have several alternate 'plugin' modules. When you do an unload, references to objects that were in the shared library are replaced by references to a stub that generates an error/exception. ( That stub routine is part of the builtin dynamic load "module" . ) It doesn't involve traceing all the references -- the pointers are unchanged, but the object is changed. I have no idea what 'the Right Thing' for Python would be here -- I'm not quite clear on what you're trying to fix. I'm just volunteering an example. -- Steve Majewski
On Mon, 17 Dec 2001, Steven Majewski wrote:
However, I will add that if I *did* need an unload for anything, I would think the XlispStat semantics: unloading the module immediately and making any dangling references into exceptions, or replacing them with references to a reloaded module, would seem to be more useful than not really unloading it until all of the references are decremented (if ever) and then unloading. I can't think of a case where I would want to unload a module, where I would not want a dangling reference to something in that module to generate an exception. -- Steve
Python doesn't let you replace a reference to an object with something else -- except in special cases (e.g. with explicit weak refs) there's no way to know where references to an object might exist. So that's not a useful idea, alas. --Guido van Rossum (home page: http://www.python.org/~guido/)
On Mon, 17 Dec 2001, Guido van Rossum wrote:
I was too fuzzy in my choice of words. What I meant was not finding and replacing the references, but replacing the object to which all of the 'dangling references' point. But that won't work either: Python objects share the same head, but total size of the object structs are too variable, and I don't know it's possible to make the minimal size object show the required behaviour. But even if that is possible, another problem with implementing it in a Python extension module is that Python objects are not (except for maybe functions and things that drag along a reference to global module namespace) "owned" by their modules in anything like the association between Lisp symbols and their packages: python modules can import other modules or can dynamically add things to their namespaces. We can't just iterate through a module dict and 'zero' out all of the objects there.
So that's not a useful idea, alas.
If the problem was important enough, I think a way could be found around those problems above, but I'm still not sure that module unloading isn't a solution looking for a problem! -- Steve
In general it's impossible. You can't even replace the type pointer with a pointer to a dummy type, because it would leak any objects referenced from the original object, and it would break if the original object lived in a special free list.
Well, there are a bunch of people who want to undo a partial import, and that boils down to about the same thing. --Guido van Rossum (home page: http://www.python.org/~guido/)
participants (4)
-
Fred L. Drake, Jr. -
Guido van Rossum -
Michael Hudson -
Steven Majewski