On 07.06.2005, at 16:44, harold fellermann wrote: > import thread > > def parentThread() : > lock = thread.allocate_lock() > child = thread.start_new_thread(childThread,(parent,)) > lock.acquire() > > def childThread(parent) : > parent.lock.acquire() > do_something_with_vars_from(parent) > parent.lock.release() > # don't do anything with parents vars after releasing the lock > > > I did not test it, but I cannot see any reason why this should fail. > >> After the childThread executes parent.lock.release() execution may be >> taken away from it and given to the parent thread(note that the child >> thread hasn't quit yet). The parent thread which is waiting on the >> lock gets released and quits. Now the "still running" child thread >> tries to exit and based on my assumption attempts to call some cleanup >> func in some module which has been GC'ed due to the exit of the parent >> thread. This leads to an exception being thrown.
>> Referencing the module locally on the child thread does not seem like an >> elegant solution besides I don't know which modules are involved in >> cleaning I wander how much an issue this fear really is. To my understanding, this situation can only happen, when the child thread accessess a module that was imported locally within the parent thread. Does anyone with a better understanding of the internals of the interpreter know whether such a thing can occur? If so, in what circumstances? - harold - -- The opposite of a correct statement is a false statement. But the opposite of a profound truth may be another profound truth. -- Niels Bohr -- http://mail.python.org/mailman/listinfo/python-list
