Christian wrote: > > Joe Holloway schrieb: > > ImportError: Failed to import _strptime because the import lockis > > [sic] held by another thread. > > The error message is my fault. The cause of the mistake is obvious:
No worries. The error message is clear even with the minor typo, I just wanted to recreate it here in case someone is searching for it down the road. > > Like I mentioned, it's only happened on a couple occasions because the > > right conditions have to be in place, but something doesn't seem right > > about it. I thought I'd ask on the mailing list before going so far > > as to open a ticket, but feel free to direct me there if that's the > > appropriate place for this. > > I have an idea what might happen in your application. Is an import > triggering the start of a thread? Not that I'm aware of. When the error is triggered, my module is simply calling into a library that's then calling into time.striptime(). The import that fails seems to be just a side effect of this. > You can get around the issue by decoupling imports from thread > startups. Your application should import all modules before it > starts its threaded components. To give you a better idea of the scenario, this is a Django web application deployed inside a WSGI container (mod_wsgi+Apache2). Ultimately, I'm not sure I have any control over when the imports occur since the WSGI container is what's managing the threads and my application is just being plugged into that container, if that makes sense. Consider that two URL handlers are likely be implemented in separate modules and hence both require a different set of imports. If both are served concurrently and one of them is making the first call to strptime while the other one has acquired the import lock, this can fail. Failing is obviously better than deadlocking, but it seems like pushing the workaround higher up in the call stack would cause some serious abstraction leaks. I don't fully understand what was causing the original deadlock, but my module should be able to call into time.strptime without incurring an ImportError or a deadlock under any circumstance? > For now you can decrease the severity of your issue by placing "import > _strptime" next to "import time" somewhere in your code. Once it a > module is loaded PyImport_ImportModuleNoBlock() will not fail to import > it a second time. Thanks for the workaround. I'm not all that concerned about the functional impact this has on my application since it has only happened a couple of times over the course of 6 weeks or so. My intent was more to make it visible in case there's a deeper design issue that can be addressed. Take care, Joe -- http://mail.python.org/mailman/listinfo/python-list
