[Interest] QtConcurrent and event-driven objects

[Bo Thorsen]

On 01/26/2015 11:56 AM, Dmitriy Purgin wrote:
> Hi,
>
> I'm using Qt to power an application server with multithreaded TCP
> listener and maintenence tasks running in separate threads. The TCP
> listener runs in main thread and spawns a separate thread to handle
> socket operation. The socket is being created when the thread is running
> using a socket descriptor passed from the TCP listener. The maintenance
> threads hold a timer only and run on timer shot to query DB and do stuff
> (doesn't really matter).
>
> The thing is, I have always used it like this:
>
> // [L1] Listing 1
> // this simplified sample code neglects cleanup and possible memory leaks
> class MaintenanceWorker : public QObject
> {
>      Q_OBJECT
>
> public:
>      MaintenanceWorker()
>          : QObject(NULL),
>            mTimer(NULL)
>      {
>          // executes in main thread
>          moveToThread(&mThread);
>          connect(&mThread, SIGNAL(started()), this,
> SLOT(onThreadStarted()));
>      }
> private slots:
>      void onThreadStarted()
>      {
>          // executes in spawned thread
>          mTimer = new QTimer();
>          connect(mTimer, SIGNAL(timeout()), this, SLOT(onTimerTimeout()));
>          mTimer->start(60000);
>      }
>
>      void onTimerTimeout()
>      {
>          // executes in spawned thread
>      }
> private:
>       QThread mThread;
>       QTimer* mTimer; // to be created in thread
> };
>
> After porting the project from Qt 4 to Qt 5 (using Qt 5.3 now) I've
> decided to use high-level QtConcurrent facilities and namely QThreadPool
> for its ability to reuse threads, control pool size and so on. So the
> sample code above was transformed into this:

Sorry, but I'm not going to actually answer your question :)

This decision doesn't make much sense to me. The timer seems to go 
against the idea of using the threadpool in the first place. So here's 
what I would do:

1) Keep your old design. It works and unless you often delete and create 
new threads, you won't get better performance with the new code.

or

2) Move the timers to a single job creator. Possibly the same object 
that holds the thread pool. In here you create the tasks from the timers 
and give them to the pool.

A runnable object is usually a simple task that needs to be done 
"sometime soon". This suggests that the tasks you have are really what 
happens when the timer fires, which is why I would expect you to go to 
number 2).

The design you implement now feels like you just want to use a different 
set of thread classes, but you don't consider what this means for your 
own code design.

So my advice is: Go all the way with the new design, or stick with what 
you have that is already working.

I hope this helps.

Bo Thorsen,
Director, Viking Software.

-- 
Viking Software
Qt and C++ developers for hire
http://www.vikingsoft.eu