This is a bug in python 2.4 under Linux 2.6.
I occasionally see subprocess.Popen() fail to return, and I have
finally figured out roughly what's going on. It involves the GC and
stderr.
1. os.fork()
2. Parent blocks reading from errpipe_read (subprocess.py:982)
3. In child, a GC occurs before t
No redesign necessary. I simply make M be the Queue's mutex, via the
LQueue class I posted. I am making the modest suggestion that this
feature be documented and exposed in the Queue class.
--
http://mail.python.org/mailman/listinfo/python-list
This is a reply to Alan Morgan, Paul McGuire and Duncan Booth.
I need mutex M because I have other fields in my class that need to be
thread-safe.
The reason I want to use a Queue and not a list is that a Queue has
additional synchronization besides the mutex. For instance, Queue.get()
will block
If you don't want to call it deadlock, fine, but the program execution
I describe will make no progress to the end of time. Thread 2 can never
put anything in the queue, because Thread 1 holds M, and Thread 1 will
never release M because that can only happen if someone puts something
on the queue.
I think there's a slight design flaw in the Queue class that makes it
hard to avoid nested monitor deadlock. The problem is that the mutex
used by the Queue is not easy to change. You can then easily get
yourself into the following situation (nested monitor deadlock):
Say we have a class that cont