"Jonathan Amsterdam" <[EMAIL PROTECTED]> writes:
> 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.
>
Even though LQueue is the correct sollution to th
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
> "Paul McGuire" <[EMAIL PROTECTED]> (PM) wrote:
>PM> "Jonathan Amsterdam" <[EMAIL PROTECTED]> wrote in message
>PM> news:[EMAIL PROTECTED]
>>> 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
>>>
"Jonathan Amsterdam" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> 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 Q
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
In article <[EMAIL PROTECTED]>,
Jonathan Amsterdam <[EMAIL PROTECTED]> wrote:
>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
>nev
"Jonathan Amsterdam" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> As I'm new to the Python community, I'm not sure that this is the right
> forum for this suggestion. Is it the sort of thing one would put on the
> SourceForge bug list? Advice appreciated.
As a sometimes bug revi
"Jonathan Amsterdam" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> 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 wil
Jonathan Amsterdam wrote:
> 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 so
On Mon, Apr 17, 2006 at 09:41:37AM -0700, Jonathan Amsterdam wrote:
> 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 rel
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.
"Jonathan Amsterdam" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> 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
> yourse
Jonathan Amsterdam <[EMAIL PROTECTED]> wrote:
...
> As I'm new to the Python community, I'm not sure that this is the right
> forum for this suggestion. Is it the sort of thing one would put on the
> SourceForge bug list? Advice appreciated.
Posting a patch and/or bug to Sourceforge is probably
13 matches
Mail list logo
