On Thu, 17 Mar 2016, Luiz Capitulino wrote:
> For some modes like MODE_CLOCK_NANOSLEEP, the clock
> is already ticking when 'stop' is initialized. This
> shouldn't matter, as this memset() should very fast
> (I'd guess a few dozens or hundrends nanoseconds at
> most?), but I also think there's no reason to do it
> this late. So, initialize it along with everything
> else.
>
> Signed-off-by: Luiz Capitulino <lcapitulino@xxxxxxxxxx>
> ---
> src/cyclictest/cyclictest.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/src/cyclictest/cyclictest.c b/src/cyclictest/cyclictest.c
> index f5a67dc..202939f 100644
> --- a/src/cyclictest/cyclictest.c
> +++ b/src/cyclictest/cyclictest.c
> @@ -829,6 +829,8 @@ static void *timerthread(void *param)
> tspec.it_interval = interval;
> }
>
> + memset(&stop, 0, sizeof(stop));
> +
> memset(&schedp, 0, sizeof(schedp));
> schedp.sched_priority = par->prio;
> if (setscheduler(0, par->policy, &schedp))
> @@ -868,10 +870,10 @@ static void *timerthread(void *param)
> tsnorm(&next);
>
> if (duration) {
> - memset(&stop, 0, sizeof(stop)); /* grrr */
> stop = now;
> stop.tv_sec += duration;
> }
> +
> if (par->mode == MODE_CYCLIC) {
> if (par->timermode == TIMER_ABSTIME)
> tspec.it_value = next;
> --
> 2.1.0
>
> --
Not sure about this one. It might be okay, but it certainly
makes the code messier. Is this just a theorectical possibility
or do you have some evidence that this is a problem?
I think I'll skip it for now unless you can show that it's a
real problem.
Thanks
John
--
To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
