Queue enhancement suggestion

[Hendrik van Rooyen]

"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.

> 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...

> > If I were faced with the sort of thing addressed by this thread, I would
> > probably use some sort of time out to decide when the end has happened.
> > After all - if the task is long running, it never stops (hopefully), and if
its
> > a batch type job, it runs out of input and stops putting stuff on the queue.
>
> This is unworkable for worker threads in a gui environment.

This is also true - when input comes from a user, time outs are no good.

- Hendrik