Michael Bayer wrote: > i was just going through this thread: http://mail.python.org/ > pipermail/python-list/2006-April/336948.html , where it is suggested > that the Lock instance used by Queue.Queue should be publically > configurable. I have identified another situation where a Queue can > be deadlocked, one which is also alleviated by configuring the type > of Lock used by the Queue (or just changing it to an RLock). > > The scenario arises when the Queue is operated upon within the > __del__ method of an object; since __del__ can be called at somewhat > unpredictable times, I have observed that it is in fact possible, in > extremely rare circumstances, for put() to be called within a get() > or possibly vice versa; since both methods lock on the same > underlying mutex object which is an instance of threading.Lock, a > deadlock occurs. > > The issue can be fixed by substituting a threading.RLock for the > threading.Lock object that Queue instantiates by default.
Please a patch on SourceForge, and send an email to python-dev to alert people of this issue (SourceForge isn't sending notification emails). Tim Delaney -- http://mail.python.org/mailman/listinfo/python-list
