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. Jean-Paul -- http://mail.python.org/mailman/listinfo/python-list
