On 10/23/12, Alan Ezust <alan.ez...@gmail.com> wrote:
>
> http://www.ics.com/designpatterns is one place where you can see the book's
> contents and download the code examples. It requires you to register/login
> but it's free.
>
Which example are you referring to? Life or PrimeThreads? I read the
whole chapter on QThreads and QtConcurrent...
I stopped reading Life's source when you called
QtConcurrent::blockingMappedReduced from the main window class (these
aren't the designs I'm looking for).
I am pretty sure the reason your QtConcurrent version of PrimeThreads
is significantly faster than the QThread version is because:
a) QtConcurrent pre-generates the list of numbers to check against ahead of time
b) The QThread version QMutex-grabs the next number each time
c) Generating prime numbers scales horizontally... though I guess your
for loop generating QThreads should too... so maybe (c) shouldn't be
here
I'm inclined to believe that QtConcurrent::filter() uses something
similar to QMutex behind the scenes... but maybe not? Maybe
QtConcurrent::filter() is more optimized while still providing similar
functionality (without using QMutex specifically)? I don't know how
it's implemented. However the tests already don't seem fair.
For the example I'm creating I am not demonstrating resource sharing
so I'm not going to use QMutex anywhere... and I can't determine a
reason that a single long running (non-horizontally-scaling) backend
would benefit from using QtConcurrent (especially since with
QtConcurrent it will just be 1 QThread pulled out of a QThreadPool
anyways, right?).
I was hoping for the tl;dr answer... but your book is a good read
either way :-P...
On 10/24/12, Bo Thorsen <b...@fioniasoftware.dk> wrote:
> Hmm, not sure. It looks to me like the problem is again just moved
> somewhere else. The "Would be dangerous to call methods" comment shows
> this problem. Using a QThread is difficult to get right, so by trying to
> hide this fact, you could end up giving the impression that it isn't. I
> usually prefer exposing the problems to the developer, unless they can
> be removed by a helper class. In some cases you can do this, in the
> general QThread case you can't. Otherwise it would already have been done.
>
Threading in general has a million ways to mess something up. That
stack-object-within-run design is the best one I've read/thought-up so
far. If you have any better suggestions, I'm all ears. That's the
purpose of this thread. Adding a note in the docs saying not to call
methods directly on the object emitted via readyForConnections() is
far better than most solutions. It's already ridiculously easy to
screw up overriding run() or moveToThread() as it is. The signal name
itself "readyForConnections" will be constantly reminding the user of
it's purpose, lessening the chance that they'll screw up it's usage by
calling a method on it directly.
Definitely getting ahead of myself with this question: is there a way
to use templates with a variable amount of T's? Sort of like those
ellipses in method parameters? I'd also need a variable amount of
parameters for my readyForConnections() signal (*gasp*, famous last
words?)... it would emit the types as parameters in the same order I
pass them in to the template.
^What I'm trying to accomplish with that is:
run()
{
UserObject1 obj1;
UserObject2 obj2;
emit readyForConnections(&obj1, &obj2);
exec();
}
...etc so I can have N amount of objects on the thread. Already pretty
sure I can do it with just 1 template type (haven't tested lol).
I'd also want to stay C++ 98 compliant.
MOC can definitely do this :). At least hackily (signals/slots are
hacks imo... just really amazing ones!!!).
For now I still think just with a single T it's a pretty sweet/clean
design. I hope I don't run into unforeseen problems during the rewrite
=o.
d3fault
_______________________________________________
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
