You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hi,
writing my server application i've found that long operations can easily cause the application to become irresponsive until the completion.
Since the tests i've done i don't see the need to enable the multithreading support of QHttp since the overhead of the lib is really really low (well done), so possibly i'd use a single threaded listener for connections but i have the need to move to some workers threads the execution of the ops related to each specific request.
Is this the right approach? Can you suggest me the 'best' way to do such thing with QHttp?
I have the feeling that i'm gonna encounter such affinity problems with the QNetworkAccessManager this way but i'm not sure of this (expecially to transmit back the reply).
Thank you!
Please, keep doing this great job.
The text was updated successfully, but these errors were encountered:
@gianks
the best approach to multithreading is domain specific and Qt5 has different tools and strategies. I'm not sure if i can help, but these are the approaches i've used:
QObject::moveToThread(): moves a constructed QObject to another thread. you can override QHttpServer::incomingConnection(QHttpConnection* connection) and then move the connection handler, for instance.
seems like a dirty hack and I'm not sure if this is the best approach.
overrinding QHttpServer:: incomingConnection(qintptr handle): you can safely move a socket descriptor to another handler thread, create your objects there and ..., saner and cleaner approach.
a simple load balancer can be implemented this way.
design every thing on Qt main thread (including QHttp or QNAM), but use QtConcurrent::run<>() and QFutureWatcher for long or blocking jobs. looks a lot cleaner. personally I use this approach extensively for simpler tasks.
but sometime I prefer to have a bunch of worker threads (for slow SQL connections, intensive disk i/o jobs, ...) and just communicate to them by some sort of Command Pattern or passing messages.
there you can use Qt's fantastic signal/slot mechanism which works like a charm between threads, or packing every job into a Command (msgpack or json) and transfer it as a message, same thing can be done by the job's Response.
Hi,
writing my server application i've found that long operations can easily cause the application to become irresponsive until the completion.
Since the tests i've done i don't see the need to enable the multithreading support of QHttp since the overhead of the lib is really really low (well done), so possibly i'd use a single threaded listener for connections but i have the need to move to some workers threads the execution of the ops related to each specific request.
Is this the right approach? Can you suggest me the 'best' way to do such thing with QHttp?
I have the feeling that i'm gonna encounter such affinity problems with the QNetworkAccessManager this way but i'm not sure of this (expecially to transmit back the reply).
Thank you!
Please, keep doing this great job.
The text was updated successfully, but these errors were encountered: