[MAL] > I wonder whether a general lock such as the one used in import > is such a good idea. Perhaps it should only lock the importing > of a specific module, keeping the locks in a dictionary indexed by > module name instead of a static C variable ?! I've been thinking along the same lines. We could make the import locking much finer-grained, and limit the blocking only to threads that are importing a module that is in the middle of being loaded by some other thread. But this is hard work, and I suggest that we put this off until Python 2.4 so we can do it right. > Then again it's hard to know the real name of the module being > searched before finding it... There could be a short-lived lock for that problem. > I see a more general problem here: the lock prevent starting > up threaded applications which use client-server logic between > the threads. If the application's main thread starts a client > thread as a result of an import which then tries to import > other Python modules, you have a deadlock. (At least that's how > I understand the current implementation.) Correct. > Don't know about others, but I frequently use the idiom of > placing the server's main code in a separate module and then > have small startup script importing this module. This kind > of setup is also advertised for CGI programs, so it may not > be uncommon out there. We had this problem with Zope2 -- I don't know why the import lock didn't bite us before, but we decided to change the Zope startup code so that you have to import Zope first and then, separately, make a call to start it. You could do the same for your application, and I recommend that Mark does the same for his. --Guido van Rossum (home page: http://www.python.org/~guido/)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4