Queue enhancement suggestion

[Jean-Paul Calderone]

On 17 Apr 2007 14:32:01 GMT, Antoon Pardon <apardon at forel.vub.ac.be> wrote:
>On 2007-04-17, Jean-Paul Calderone <exarkun at divmod.com> wrote:
>> On 17 Apr 2007 13:32:52 GMT, Antoon Pardon <apardon at forel.vub.ac.be> wrote:
>>>On 2007-04-17, Hendrik van Rooyen <mail at microcorp.co.za> 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