[Interest] Heavily Commented Example: Simple Single Frontend with Two Backends

[d3fault]

On 10/23/12, Alan Ezust <alan.ezust at gmail.com> wrote:
> Actually, it's not as simple as I stated. Basically, adding a widget to a
> layout
> makes it the child of the widget that it is a layout for. So if you add a
> widget to a sub-layout,
> it actually won't be the sibling of that layout object, but an uncle or
> something.
>

Weird, so what you're saying is:

QWidget 'this' parent
_Layout
_Layout1Widget1
_Layout1Widget2
__SubLayout1 // added via Layout.addLayout(), Layout now being his parent
_SubLayout1Widget1
_SubLayout1Widget2
__SubLayout2 // ditto
_SubLayout2Wiget1
___SubSubLayout3 // added via SubLayout2.addLayout(), SubLayout2 now
being his parent
_SubSubLayout3Widget1
_SubSubLayout3Widget2

With everything that's a widget being a sibling and a direct child of 'this'?

I guess that makes sense. I think I'm better off just removing the
part of the comment that's wrong than trying to explain that (but the
QWidget::setLayout docs should (and don't) explain it!).


>
> Regarding rewriting the example, I think the best way to rewrite it is to
> remove all usage of QThread entirely, and see if you can figure out how to
> program it using the higher-level QtConcurrent  API. In my book [Intro to
> Design Patterns in Qt, 2nd edition], I show another multithreaded example
> written both ways and the QtConcurrent version performs much better.
>

> book
I wish I could see what you're talking about :-P. My goal in making
that example is/was to have a simple and easy to understand reference
that implements a clean and re-usable design. Performance was not a
huge concern, but I wouldn't say it isn't important.

Why would QtConcurrent be more performant if they both use QThreads in
the background? I'm under the impression that QtConcurrent is meant
for.. err... problems... that scale horizontally. Yes my use of
QCryptographicHash would scale horizontally, but not everything can.
Is QtConcurrent still more performant in those cases where we can't
scale horizontally? If so, I'll look more into rewriting it under
QtConcurrent (if I could see the example in your book I could answer
this myself).

At a glance (I've read all the QtConcurrent docs previously, but have
yet to actually use it... so I guess I should say "at a re-glance"),
it looks like I could use that template-based readyForConnections()
emitting design described in my previous email very easily within
QtConcurrent::run(). However, then I saw this: "Note that the function
may not run immediately; the function will only be run when a thread
is available" (
http://qt-project.org/doc/qt-4.8/qtconcurrentrun.html#run ). Within a
large application with many backend objects/threads (doing different
things, so they can't scale horizontally), it sounds sub-optimal to
not be able to have them all running at the same time. You could
override QThreadPool's max thread count, but idk that just seems
hacky. Aren't thread pools meant for numerous shorter living units of
execution? I recall reading somewhere something along the lines of "if
you are going to keep the thread alive for a long time, use QThread
instead". The example, and the design I'm trying to perfect, is the
long-standing single (or I guess double lol) backend thread.

If I'm wrong and setting QThreadPool's max thread count to be >= your
backend object count on a per-project basis isn't a dirty hack
(separation of concerns!)... and if QtConcurrent really performs that
much better... I'll probably use it for the rewrite. Thanks :)

d3fault