[Interest] QtConcurrent and event-driven objects

[Dmitriy Purgin]

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 <bo at 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 at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20150127/ce534650/attachment.html>