On 2007-04-17, Jean-Paul Calderone [EMAIL PROTECTED] wrote:
On 17 Apr 2007 14:32:01 GMT, Antoon Pardon [EMAIL PROTECTED] wrote:
On 2007-04-17, Jean-Paul Calderone [EMAIL PROTECTED] wrote:
On 17 Apr 2007 13:32:52 GMT, Antoon Pardon [EMAIL PROTECTED] wrote:
On 2007-04-17, Hendrik van Rooyen [EMAIL
On 2007-04-18, Hendrik van Rooyen [EMAIL PROTECTED] wrote:
Antoon Pardon [EMAIL PROTECTED] wrote:
The problem is that sometimes the gui thread has something to show
too. With the added problem that the code wanting to show something
doesn't know when it is executing the gui thread or an
On 2007-04-17, Paul Rubin http wrote:
Antoon Pardon [EMAIL PROTECTED] writes:
The problem is this doesn't work well if you have multiple producers.
One producer can be finished while the other is still putting values
on the queue.
Right, you'd wait for all the producers to finish, then
On 2007-04-17, Hendrik van Rooyen [EMAIL PROTECTED] wrote:
Antoon Pardon [EMAIL PROTECTED] wrote:
The problem is this doesn't work well if you have multiple producers.
One producer can be finished while the other is still putting values
on the queue.
The solution I have been thinking on is
On 17 Apr 2007 14:32:01 GMT, Antoon Pardon [EMAIL PROTECTED] wrote:
On 2007-04-17, Jean-Paul Calderone [EMAIL PROTECTED] wrote:
On 17 Apr 2007 13:32:52 GMT, Antoon Pardon [EMAIL PROTECTED] wrote:
On 2007-04-17, Hendrik van Rooyen [EMAIL PROTECTED] wrote:
[snip]
Not sure I understand this - it
Antoon Pardon [EMAIL PROTECTED] wrote:
On 2007-04-17, Hendrik van Rooyen [EMAIL PROTECTED] wrote:
Antoon Pardon [EMAIL PROTECTED] wrote:
The problem is this doesn't work well if you have multiple producers.
One producer can be finished while the other is still putting values
on the
On 2007-04-17, Hendrik van Rooyen [EMAIL PROTECTED] wrote:
Antoon Pardon [EMAIL PROTECTED] wrote:
On 2007-04-17, Hendrik van Rooyen [EMAIL PROTECTED] wrote:
Antoon Pardon [EMAIL PROTECTED] wrote:
The problem is this doesn't work well if you have multiple producers.
One producer can
On 2007-04-17, Jean-Paul Calderone [EMAIL PROTECTED] wrote:
On 17 Apr 2007 13:32:52 GMT, Antoon Pardon [EMAIL PROTECTED] wrote:
On 2007-04-17, Hendrik van Rooyen [EMAIL PROTECTED] wrote:
[snip]
Not sure I understand this - it sounds vaguely incestous to me.
I normally use a GUI with two
On 17 Apr 2007 13:32:52 GMT, Antoon Pardon [EMAIL PROTECTED] wrote:
On 2007-04-17, Hendrik van Rooyen [EMAIL PROTECTED] wrote:
[snip]
Not sure I understand this - it sounds vaguely incestous to me.
I normally use a GUI with two queues, one for input, one for
output, to two threads that
The problem is that sometimes the gui thread has something to show
too. With the added problem that the code wanting to show something
doesn't know when it is executing the gui thread or an other. So
it is very difficult to avoid the gui thread putting things on the
queue. But since the gui
Antoon Pardon [EMAIL PROTECTED] wrote:
The problem is that sometimes the gui thread has something to show
too. With the added problem that the code wanting to show something
doesn't know when it is executing the gui thread or an other. So
it is very difficult to avoid the gui thread putting
I'd like to suggest adding a new operation
Queue.finish()
This puts a special sentinel object on the queue. The sentinel
travels through the queue like any other object, however, when
q.get() encounters the sentinel, it raises StopIteration instead
of returning the sentinel. It does not
Paul Rubin wrote:
I'd like to suggest adding a new operation
Queue.finish()
This puts a special sentinel object on the queue. The sentinel
travels through the queue like any other object, however, when
q.get() encounters the sentinel, it raises StopIteration instead
of returning the
On 2007-04-16, Paul Rubin http wrote:
I'd like to suggest adding a new operation
Queue.finish()
This puts a special sentinel object on the queue. The sentinel
travels through the queue like any other object, however, when
q.get() encounters the sentinel, it raises StopIteration instead
On Apr 15, 11:12 pm, Paul Rubin http://[EMAIL PROTECTED] wrote:
I'd like to suggest adding a new operation
Queue.finish()
This puts a special sentinel object on the queue. The sentinel
travels through the queue like any other object, however, when
q.get() encounters the sentinel, it
On 15 Apr 2007 23:12:34 -0700, Paul Rubin http://phr.cx@nospam.invalid
wrote:
I'd like to suggest adding a new operation
Queue.finish()
This puts a special sentinel object on the queue. The sentinel
travels through the queue like any other object, however, when
q.get() encounters the
Jean-Paul Calderone [EMAIL PROTECTED] writes:
Instead of putting multiple sentinels, just pre-construct the iterator
object.
work = iter(q.get, sentinel)
Re-use the same iterator in each thread, and you'll get the behavior
you're after.
Whaaat??? Can I do that? It looks like it
Antoon Pardon [EMAIL PROTECTED] writes:
The problem is this doesn't work well if you have multiple producers.
One producer can be finished while the other is still putting values
on the queue.
Right, you'd wait for all the producers to finish, then finish the queue:
for p in
Antoon Pardon [EMAIL PROTECTED] wrote:
The problem is this doesn't work well if you have multiple producers.
One producer can be finished while the other is still putting values
on the queue.
The solution I have been thinking on is the following.
Add an open and close operation. Only
19 matches
Mail list logo
