Closed DengZuoheng closed 5 years ago
I confirm you figures.
https://wandbox.org/permlink/Z3oiCHlYTsMQdOk6
The difference is between 1.66 and 1.67 and my understanding is as well that the result for 1.66 are better.
However, the results for 1.67 and 1.69 are also good. This is because the request is to execute after the specified duration and the exeution take place after this duration is elapsed.
I believe the changes is due to https://github.com/boostorg/thread/issues/162 fix as much time-related issues as possible and improve the QOI
need to check for the concerned commits.
I suspect that the issue was introduce by this change (https://github.com/boostorg/thread/commit/e96516d10d32ec54c43d3a0a148a0ac79b207168#diff-fca6695c01c8ed364635a2532c8c2564), but I'm not sure yet.
@austin-beer, Austin please, could you take a look?
Yes, I will take a look and get back to you with what I find.
Yes, this issue was introduced by the commit you referenced. I've created a pull request to fix this issue.
I've merged the PR. @DengZuoheng please could you confirm this restores the behavior of 1.69?
It would be great to have a test that do the real check, not a visual one (using e.g. stream streams or something else).
@DengZuoheng, @austin-beer would some of you mind to provide it?
I'm not sure I could integrate it fo Boost.1.70 as the beta test is already on the air. I will try.
Thanks @DengZuoheng for your report and thanks @austin-beer for the collaboration.
I think I can create an automated test case based on the code we used to manually test this issue. I'll try to get a PR for it in the next day or two.
I've created a PR that adds a simple test case for this issue: https://github.com/boostorg/thread/pull/273
I've merged it :)
I re-ran the time jump tests and discovered that my fix for this issue re-introduced some time jump issues with sync_timed_queue. I've submitted a PR to address that: #277.
In following code, every 500ms submit a work, but each work's time duration less than before:
1.69 behave different with 1.66, while 1.66's output is:
but 1.69's output is
1.66 is what I want. It's that a bug of 1.69 or I use it wrong?
Thanks.