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 _______________________________________________ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest