"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 queue. > >> > >> The solution I have been thinking on is the following. > >> > >> Add an open and close operation. Only threads that have the queue > >> open can access it. The open call should specify whether you > >> want to read or write to the queue or both. When all writers > >> have closed the queue and the queue is empty a q.get will > >> raise an exception. This may be done by putting a sentinel > >> on the queue when the last writer closed the queue. > >> > > > > This is beginning to look like a named pipe to me. > > > > The nice thing about queues is that there is currently so little > > BS about them - you just import the module, create one by binding > > a name to it, and you are in business, and anyone can read and/or > > write to it. > > And if you are not carefull you have a deadlock. I tried queues > in a threaded gui application. Al the advise you get about such > applications tell you to have one thread doing all the gui-stuff.
This is true - and worse - it needs to be the main thread too. > So you basically have n producers and one consumer. Unfortunatly > the gui thread sometimes has things of its own it want to show. > So when the gui thread wants to put things on the queue you > risk a deadlock. 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 front end two named pipes to the next process - I try to avoid more than one thing reading or writing to one end of a queue or a pipe, so the dataflow diagram for my stuff always looks like a TinkerToy... > > If I were faced with the sort of thing addressed by this thread, I would > > probably use some sort of time out to decide when the end has happened. > > After all - if the task is long running, it never stops (hopefully), and if its > > a batch type job, it runs out of input and stops putting stuff on the queue. > > This is unworkable for worker threads in a gui environment. This is also true - when input comes from a user, time outs are no good. - Hendrik -- http://mail.python.org/mailman/listinfo/python-list
