action #116554
Updated by okurz over 1 year ago
## Motivation We have multiple places in os-autoinst where we consider a "no_wait" scenario but use different sleeping times, e.g. 0.01s in https://github.com/os-autoinst/os-autoinst/pull/2109/files vs. 0.1s in https://github.com/os-autoinst/os-autoinst/pull/2164/files#diff-ee84fe6541d1e2e971e9e0d4bf0187272df8fa4ac878d033b1c8c600325e9f6dR185 . We should better avoid magic numbers with inconsistent usage for the same ## Acceptance criteria * **AC1:** In all cases of check_screen/assert_screen/wait_screen_change/wait_still_screen only a fraction of a second is spent when the expected screen content is already showing up (either in general or only if "no_wait" is used) * **AC2:** We only use one common definition of a sleep interval (or timeout) ## Suggestions * Review the history when "no_wait" was introduced. "no_wait" was first introduced in commit e2b9c835, Author: Oliver Kurz <okurz@suse.de>, Date: Thu Jan 26 14:59:26 2017 +0100 "Add optional 'no_wait' parameter for check/assert_screen". The "no_wait" in "wait_still_screen" with 0.01s was introduced in f2a31c64 * Review occurences from `$ git grep '\(sleep\|interval\).*\.0\?1'` related to sleeping between test API checks ``` … backend/baseclass.pm: # note: Still keeping the interval at 0.1 s to avoid wasting too much CPU (corresponding to what check_screen/assert_screen backend/baseclass.pm: my @additional_intervals = $wait_screen_change && $wait_screen_change->{no_wait} ? (0.1) : (); … testapi.pm: sleep($args{no_wait} ? 0.01 : 0.5); ``` there might be an additional 0.1s somewhere in isotovideo that mkittler mentioned. At best we can define the number with 0.01 consistently in a single place and use from there following up with what https://github.com/os-autoinst/os-autoinst/pull/2109/files#diff-3420c7e01f73caee7d97053af39990e3297daf42d06e0fc8848f78af1a5e009eR565 tried to do already. * It might be **But please also read #116554#note-2** because I must say that the best solution to get rid of sleep calls completely if that ticket description is not required. Please check the impact on CPU usage when removing the sleep call * Keep in mind that in one case we have an actual sleep call, in the other case it's an interval/timeout for something slightly different misleading/problematic as-is.