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

Simpler timeout with QTimer::singleShot #4435

Merged
merged 3 commits into from
Nov 10, 2019

Conversation

MartinDelille
Copy link
Contributor

This fix the problem mentionned here: #4430 (comment)

  • Read the contribution guidelines.
  • If contributing template-only or documentation-only changes which will change sample output, build the project before.
  • Run the shell script(s) under ./bin/ (or Windows batch scripts under.\bin\windows) to update Petstore samples related to your fix. This is important, as CI jobs will verify all generator outputs of your HEAD commit, and these must match the expectations made by your contribution. You only need to run ./bin/{LANG}-petstore.sh, ./bin/openapi3/{LANG}-petstore.sh if updating the code or mustache templates for a language ({LANG}) (e.g. php, ruby, python, etc).
  • File the PR against the correct branch: master, 4.3.x, 5.0.x. Default: master.
  • Copy the technical committee to review the pull request if your PR is targeting a particular programming language.

@ravinikam @stkrwork @etherealjoy @muttleyxd

@MartinDelille
Copy link
Contributor Author

This mistake leverage a lack in our testing: the CI should test that client has been updated.

@etherealjoy
Copy link
Contributor

etherealjoy commented Nov 10, 2019

https://doc.qt.io/qt-5/qobject.html#disconnect
Disconnect everything connected to an object's signals:

disconnect(myObject, 0, 0, 0);

So indeed original code below is correct.

void PFXHttpRequestWorker::on_manager_timeout(QNetworkReply *reply) {
    error_type = QNetworkReply::TimeoutError;
    response = "";
    error_str = "Timed out waiting for response";
    disconnect(manager, nullptr, nullptr, nullptr);
    reply->abort();

I was trying to suggest this below, but since the code was reworked in your PR I got confused.

void PFXHttpRequestWorker::on_manager_finished(QNetworkReply *reply) {
    if(timer->isActive()){
        timer->stop();
    }
    disconnect(timer, nullptr, nullptr, nullptr);
    error_type = reply->error();
    response = reply->readAll();
    error_str = reply->errorString();

The idea is that, once we received the response callback, we should deactivate timer to avoid the timeout from triggering.
And once we received the timeout callback we disconnect the response callback.

@MartinDelille
Copy link
Contributor Author

Do we really need to disconnect in the end?

@etherealjoy
Copy link
Contributor

Yes we do.
I edited my post above.

@etherealjoy
Copy link
Contributor

So we dont get both the callbacks for each API call.

@MartinDelille
Copy link
Contributor Author

Ok so I push the new fix

@etherealjoy
Copy link
Contributor

Ok so I push the new fix

This should solve one topic related to disconnect response callback when timeout.
We need to disconnect the timer callback if we receive the response.

@etherealjoy
Copy link
Contributor

There is another bug in this branch.

void PFXHttpRequestWorker::setTimeOut(int timeOut){
    _timeOut = _timeOut;
}

self assignment.

@MartinDelille
Copy link
Contributor Author

MartinDelille commented Nov 10, 2019

We need to disconnect the timer callback if we receive the response.

But the worker is deleted later in the callback. Shouldn't it disconnect from the futur timer event? (https://doc.qt.io/qt-5/qobject.html#deleteLater)

self assignment.

My bad! 😅

@etherealjoy
Copy link
Contributor

etherealjoy commented Nov 10, 2019

But the worker is deleted later in the callback. Shouldn't it disconnect from the futur timer event?

I think it is OK.

void QObject::deleteLater()

Note: It is safe to call this function more than once; when the first deferred deletion 
event is delivered, any pending events for the object are removed from the event queue.

Lets see if there are issues reported later.
I am just concerned about race conditions when the signals are queued across threads using QueuedConnection.

@MartinDelille
Copy link
Contributor Author

Ok I pushed the self assignement fix.

I think this should be the worker responsability to delete itself later (and not the callback).

@etherealjoy etherealjoy merged commit 7e6e87a into OpenAPITools:master Nov 10, 2019
@etherealjoy etherealjoy added this to the 4.2.1 milestone Nov 10, 2019
@MartinDelille MartinDelille deleted the fix-singleshot branch November 10, 2019 16:07
@wing328 wing328 changed the title fixup! Simpler timeout with QTimer::singleShot (#4430) Simpler timeout with QTimer::singleShot Nov 15, 2019
@wing328
Copy link
Member

wing328 commented Nov 15, 2019

@MartinDelille thanks for the PR, which has been included in the v4.2.1 release: https://twitter.com/oas_generator/status/1195339336922759168

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

Successfully merging this pull request may close these issues.

3 participants