A thread import problem
d at davea.name
Sun Jul 22 00:33:05 CEST 2012
On 07/21/2012 05:35 PM, Bruce Sherwood wrote:
> On Sat, Jul 21, 2012 at 2:53 PM, Dave Angel <d at davea.name> wrote:
>> For docs on the threading thing, see:
>> " ... an import should not have the side effect of spawning a new thread
>> and then waiting for that thread in any way..."
> Thanks. I had read that as forbidding "waiting for that thread", not
> forbidding spawning a new thread. The following sentence says,
> "Failing to abide by this restriction can lead to a deadlock if the
> spawned thread directly or indirectly attempts to import a module." I
> gather that a clearer, more forceful statement might be, "Failing to
> abide by this restriction WILL lead to a deadlock if the spawned
> thread directly or indirectly attempts to import a module." All of
> which implies the behavior I've seen in various experiments, namely
> that as long as the spawned thread doesn't do any imports, I haven't
> seen any problems with spawning a thread in an imported module. I take
> your word for it that this is a no-no, but I don't know why.
> Bruce Sherwood
I don't know just what will work and what will not; But there are lots
of subtle and indirect ways of "waiting for that thread" and I suspect
that import is one of them.
Since I've never seen a case where we had to break the general rule, it
just seems easier to keep it clean. No threading inside an import.
Same with recursive imports. I could list some of the specific problems
that crop up, but since the only time recursive imports are unavoidable
is when you're constrained by preexisting 3rd party software that does
something strange, it seems easier to make a simple rule that's easy
enough to test for.
if you try to import the script (that imported you) as though it were a
module, you end up with two copies of that module, and if they have any
non-constant globals, you can get very strange symptoms. In other
More information about the Python-list