[LTP] [PATCH v1] Correctly handle user time in setitimer01
Martin Doucha
mdoucha@suse.cz
Fri Nov 4 16:44:15 CET 2022
On 04. 11. 22 15:20, Andrea Cervesato wrote:
> Hi!
>
> On 11/4/22 13:46, Martin Doucha wrote:
>> This approach looks like it'll lead to some bad edge cases when
>> 0 < time_step < 1000. It'd be better to keep the original time_step
>> detection and initialize "error" variable like this (and also rename
>> it to "margin"):
>>
>> int jiffy;
>>
>> verify_setitimer()
>> {
>> ...
>> margin = (tc->which == ITIMER_REAL) ? 0 : jiffy;
> Here we can't take in consideration CLOCK_MONOTONIC_COARSE resolution by
> default, because on ITIMER_REAL we are having a clock resolution given
> by CLOCK_MONOTONIC. And unfortunately we are not sure it's under the
> millisecond resolution all the times, which means margin > 0. For this
> reason, in the patch we are fetching clock resolution in a different
> way, according with the counter timer. We can fetch different
> resolutions from setup tho and using inside the test code.
There is nothing preventing you from using CLOCK_MONOTONIC_COARSE
resolution as time_step even for ITIMER_REAL. The only constraints are
that the timer value must be:
1) higher than CLOCK_MONOTONIC resolution (preferably a multiple of it)
2) large enough so that you can call setitimer() again before the timer
expires
CLOCK_MONOTONIC_COARSE resolution should satisfy the first constraint by
definition.
--
Martin Doucha mdoucha@suse.cz
QA Engineer for Software Maintenance
SUSE LINUX, s.r.o.
CORSO IIa
Krizikova 148/34
186 00 Prague 8
Czech Republic
More information about the ltp
mailing list