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