Queue enhancement suggestion

[Antoon Pardon]

On 2007-04-17, Jean-Paul Calderone <exarkun at divmod.com> wrote:
> 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.

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