<p>On Oct 14, 2012 11:27 AM, "Devin Jeanpierre" <<a href="mailto:jeanpierreda@gmail.com">jeanpierreda@gmail.com</a>> wrote:<br>
> I did this once, because I needed to rewrite a blocking API and wanted<br>
> to use Twisted, except that I made the mistake of starting the thread<br>
> when the module was created instead of on first call. This lead to a<br>
> deadlock because of the global import lock... :(  In principle I don't<br>
> know why this would be a terrible awful idea, if it was done right,<br>
> but maybe people with more experiences with threaded code can correct<br>
> me.<br>
><br>
> (The whole thread daemon thing necessary to make it act like a<br>
> synchronous program, might be terribly insane and therefore an idea<br>
> killer. I'm not sure.)<br>
><br>
> I'm under the understanding that the global import lock won't cause<br>
> this particular issue anymore as of Python 3.3, so perhaps starting a<br>
> reactor on import is reasonable.</p>
<p>Yeah, while a global import lock still exists, it's used just long enough to get a per-module lock.  On top of that, the import system now uses importlib (read: pure Python) for most functionality, which has bearing on threading and ease of better accommodating async if needed.</p>

<p>-import</p>