This allows the test to finish a bit earlier in the best case.
I.e. when the signal comes in after 1ms, we will only wait for 1ms,
instead of always waiting for 50ms.
Details
Details
Diff Detail
Diff Detail
- Repository
- R244 KCoreAddons
- Lint
Automatic diff as part of commit; lint not applicable. - Unit
Automatic diff as part of commit; unit tests not applicable.
| autotests/kdirwatch_unittest.cpp | ||
|---|---|---|
| 256 | but then the whole while loop could be removed too, it served the same purpose as what QSignalSpy::wait does. | |
| autotests/kdirwatch_unittest.cpp | ||
|---|---|---|
| 256 | no, since wait waits for one signal, this loop waits for up to expected signals. We could try to leverage QTRY_COMPARE_WITH_TIMEOUT but in my quick test that actually also behaves differently. That one apparently sometimes waits *too long*, yielding _more_ signals than expected. I.e. in touch1000Files it gives 102 signals and nestedEventLoop gives two dirty signals for inotify... The FAM test also fails with this, so I don't think it's a good idea to do it. Here's my attempt btw: https://paste.kde.org/pcxm8gcwz | |
Comment Actions
Oh, right. I see. Still very strange that QTRY_COMPARE_WITH_TIMEOUT behaves differently (if more signals are coming in than expected, the current (old) code could have caught them too, during the 50ms. Actually that might explain some of the flakiness I sometimes saw....
OK, that's another reason for your patch, which stops as soon as the last signal is emitted.