strptime issue in multi-threaded application

[Joe Holloway]

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