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 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 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... >>>> >>>>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 thread is the single reader, it will dead >>>>lock if the queue happens to be full at the moment the gui thread >>>>want to add another item. >>>> >>> >>> This is pretty easily solved: >>> >>> def sendToGUI(event): >>> if isInGUIThread(): >>> gui.scheduleCall(event) >>> else: >>> guiQueue.put(event) >> >>No that is not a solution for the simple reason that now things >>can be shown out of order. Suppose I have a thread that shows >>the value of a certain variable. Now I have a button that can >>stop this thread and zero the variable. If I go for your >>solution a value may still be in the queue and my window >>ends up showing this last value instead of zero. >> > > Addressing that is up to the application code. Threading is tough, > there are no magic bullets. The above is a very standard tool for > addressing the concern raised earlier in this thread. It's only > *part* of a solution though, the rest of the application has to play > along.
My solution is a more complete implementation of Queues, which allow a thread to register as reader, writer or reader-writer. Reader-writers are always allowed to put an element in the queue even if it is "full". Since the Reader-writer will typically only put things on the queue as a result of user interaction, the queue wont grow too large anyway. -- Antoon Pardon -- http://mail.python.org/mailman/listinfo/python-list
