Re: [Xenomai-help] Application broken 2.3.4 ---> 2.4.0

["Ignacio García Pérez" <iggarpe@domain.hid>]

>> Anyway, something is truly screwed up when 
>> rt_task_set_periodic(&_blink_thread, rt_timer_read(), mili2count(250)) 
>> fails to make the task periodic...
>>     
>
> That's due to the reworked timer subsystem: Starting timers (like the
> periodic task timer) in the past is reported as error - up to the
> application in this case. One may discuss if this case can be considered
> as an undocumented API change (I haven't re-read the docs in this regard
> yet).
>   
At least the rt_task_set_periodic documenations says nothing about it.

I don't know about the timer subsystem, but from the native API point of 
view, the behaviour that makes most sense is the old, that is, if I set 
a task periodic with a start time in the past, it should be scheduled 
immediately.

I hope there is a very good reason for this behaviour change, because I 
bet it is going to cause a lot of headaches to a lot of people.

For example, in a code like this:

rt_task_set_periodic(&mytask, some_time_in_the_near_future, mili2count(100))

There is always a chance that "some_time_in_the_future" is in the past 
by the time the call to rt_task_set_periodic is called (due to this task 
being delayed by some higher priority task).

WHAT am I supposed to do, check the result of each an every 
rt_task_set_periodic call???

It is clearly a case of "*better later than never*". I'd rather have the 
periodic task start scheduled a bit late than not scheduled at all.