Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Multithreading strategy #22

Open
gianks opened this issue Sep 21, 2016 · 1 comment
Open

Multithreading strategy #22

gianks opened this issue Sep 21, 2016 · 1 comment
Labels

Comments

@gianks
Copy link

gianks commented Sep 21, 2016

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.

@azadkuh
Copy link
Owner

azadkuh commented Sep 21, 2016

@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.

these may help:

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants