Hello, thanks for answering. Sorry, I might have described it not clear enough. Tasks that utilize timers and sockets are actually quite separate tasks. I used the code posted just to show the execution context.
I'll start with tasks using timers. These are executed once in a minute to do some simple jobs: check for license availability, call a stored procedure in DB to perform scheduled cleanup or look if the database has some notifications to send. I like your idea from 2), seems to be the way to go. But the central part of the application (I mentioned it least in my previous mail) is a QTcpServer instance which is an HTTP-like server. It doesn't use any timers but just listens to incoming connections. The listener spawns a new thread passing a socket descriptor to it upon seeing an incoming connection. Then the thread creates its own socket using the descriptor passed, reads data, processes it and writes back the response. Thus the sockets are not cross-threaded, they are created in an already spawned thread from the pool. The reason for using thread-per-connection approach is that the most connections produce database queries which are synchronous in Qt. So in this case threads are being constantly created and destroyed: typical HTTP session lifetime here is about a second or less and there is a constant load of 15-20 connections per second. I think it's a perfect place to use a QThreadPool instance reusing the threads whose runnables are done. My hesitation about QThreadPool handling connections of QTcpServer is the following: suppose that a thread is spawned by QThreadPool and a QTcpSocket instance is created in a QRunnable executed in the pool. Is this the case that any slot of a runnable connected to a QTcpSocket signal is actually executed in the thread that created the QThreadPool instance, just like it is the case for QTimer (see my prev. mail)? The documentation states you cannot start a timer or connect a socket in a thread that is not the object's thread. The object thread here is the QThreadPool's thread thus main thread (If I'm not wrong). The sockets don't seem to cause any problems with QThreadPool so far but I should clearly revert it back to my old design if it isn't supposed to work like this. Once again, my old design that uses QThread-only approach with my own thread pool worked as expected, the thing is I want to refactor my code to utilize more library facilities which seem to be less error-prone, more maintainable and unified. Thanks again for joining the discussion. Cheers Dmitriy 2015-01-27 14:28 GMT+06:00 Bo Thorsen <b...@vikingsoft.eu>: > On 01/26/2015 11:56 AM, Dmitriy Purgin wrote: > > Another important thing for me is network. The docs also specify that > > the network module should also follow single thread policy. Does that > > mean that an instance of QTcpSocket can't be used in QRunnable started > > by QThreadPool? > > You can only use the socket in one thread at a time. You can pass it on > to another thread, but you will find yourself with weird bugs if you do > this a lot. > > You haven't given enough information to say if this is a problem for you > or not. If the threads just send stuff over the socket, then implement > this with simple message parsing to the thread that have the socket. If > the threads handle incoming messages (which I wouldn't expect, since > you're using timers instead of handling incoming data signals), the > answer depends on whether your protocol allows out of sync answers or not. > > 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 >
_______________________________________________ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest