Queue enhancement suggestion

[Antoon Pardon]

On 2007-04-17, Hendrik van Rooyen <mail at microcorp.co.za> wrote:
>
> "Antoon Pardon" <apardon at forel.vub.ac.be> wrote:
>
>> On 2007-04-17, Hendrik van Rooyen <mail at microcorp.co.za> wrote:
>> > "Antoon Pardon" <a..n at forel.vub.ac.be> wrote:
>> >
>> >
>> >> The problem is this doesn't work well if you have multiple producers.
>> >> One producer can be finished while the other is still putting values
>> >> on the queue.
>> >>
>> >> The solution I have been thinking on is the following.
>> >>
>> >> Add an open and close operation. Only threads that have the queue
>> >> open can access it. The open call should specify whether you
>> >> want to read or write to the queue or both. When all writers
>> >> have closed the queue and the queue is empty a q.get will
>> >> raise an exception. This may be done by putting a sentinel
>> >> on the queue when the last writer closed the queue.
>> >>
>> >
>> > This is beginning to look like a named pipe to me.
>> >
>> > The nice thing about queues is that there is currently so little
>> > BS about them - you just import the module, create one by binding
>> > a name to it, and you are in business, and anyone can read and/or
>> > write to it.
>>
>> And if you are not carefull you have a deadlock. I tried queues
>> in a threaded gui application. Al the advise you get about such
>> applications tell you to have one thread doing all the gui-stuff.
>
> This is true - and worse - it needs to be the main thread too.

I think that is a window condition. On linux it can be any thread.

>> So you basically have n producers and one consumer. Unfortunatly
>> the gui thread sometimes has things of its own it want to show.
>> So when the gui thread wants to put things on the queue you
>> risk a deadlock.
>
> 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.

-- 
Antoon Pardon