bug: subprocess.Popen() hangs

2007-10-25 Thread Jonathan Amsterdam
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

Re: Queue can result in nested monitor deadlock

2006-04-18 Thread Jonathan Amsterdam
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

Re: Queue can result in nested monitor deadlock

2006-04-17 Thread Jonathan Amsterdam
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

Re: Queue can result in nested monitor deadlock

2006-04-17 Thread Jonathan Amsterdam
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.

Queue can result in nested monitor deadlock

2006-04-17 Thread Jonathan Amsterdam
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