[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