Re: [Xenomai-help] rt_task_sleep_until question

[Philippe Gerum <rpm@xenomai.org>]

Klaas Gadeyne wrote:
> On Tue, 22 Apr 2008, Philippe Gerum wrote:
> 
> [snipping even more context]
> 
>>>> What's wrong with rt_task_suspend() ?
>>>
>>> The current loop code is something like
>>>
>>> void timerloop_task_proc(void *arg)
>>> {
>>>         int ret;
>>>         int errors = 0;
>>>         do{
>>>                 do{
>>>                         last_occured_alarm = last_alarm_set;
>>>                         EnterMutex();
>>>                         TimeDispatch();
>>>                         LeaveMutex();
>>>                 }while ((ret = rt_task_sleep_until(last_alarm)) == 0);
>>>                 if (ret == -ETIMEDOUT){
>>>                   printf("[TIMERLOOP] Total errors = %d, return code =
>>> %d\n",++errors,ret);
>>>                 }
>>>         }while (!(stop_timer && ret == -EINTR));
>>>         printf("End of TimerLoop, code %d, Total errors =
>>> %d\n",ret,errors);
>>> }
>>>
>>> I could modify that code and put something like
>>> if (last_alarm == TIMEVAL_MAX) // Nothing else to do, sleep forever
>>>   rt_task_suspend()
>>> else
>>>   rt_task_sleep_until(last_alarm)
>>>
>>> However, the one who wants to wake up this thread (e.g. for asking
>>> this thread to stop) doesn't know in what state the timerthread is.
>>> It seems clumsy to me if that the one who wants to wake up the thread
>>> has to try _unblock() first, and the _resume()?
>>>
>>
>> There has been a fair amount of misunderstanding. Past mails were
>> apparently
>> aiming at rt_task_sleep's behaviour (e.g. returning 0 on NULL delay
>> etc.), but
>> you actually care for rt_task_sleep_until, which is a totally
>> different story
>> (the subject line was right though).
> 
> Sorry about that, during the debugging I ended up playing around with
> rt_task_sleep() to check if the overflow issues did occur there too.
> 
>> Handling the special TM_INFINITE value as a valid timeout value for
>> rt_task_sleep_until would not introduce the flaws I was concerned about
>> regarding rt_task_sleep. We would just change the behaviour when
>> receiving what
>> used to be an utterly bugous date spec in the current implementation,
>> and make
>> it valid, which is ok -- i.e. I'm not particularly concerned by
>> maintaining
>> backward compatible behaviours when receiving utterly insane data
>> specs like "0"
>> for an absolute date.
>>
>> If your loop was truly periodic, you could probably use
>> rt_task_wait_period(),
>> but I suspect last_alarm may not try to enforce a strictly periodic
>> timeline, right?
>>
>> The fact that we don't have any other blocking calls with absolute
>> date specs is
>> bothering me actually, and 2.5 will probably see some extensions like
>> rt_sem_p_until(), in order to address patterns of this kind.
>>
>> But well, back to rt_task_sleep_until, I see no reason not to handle
>> the corner
>> case you described a bit more gracefully. So let's try the Klaas
>> Amendment to
>> the native API.
> 
> I *really* like the way that sounds ;-)
> 
>> Does the following work for you?
> 
> [snipped patch]
> 
> It does!  Tested on today's 2.4-branch on a 2.6.20.21-ipipe-1.12-03 kernel.
> Any chance this could still be merged in the 2.4 series?
> 

Since this does not change the behaviour of documented and valid use cases, I
will merge that patch into 2.4.4.

> Thx for your patience!
>

You are welcome.

> Klaas
> 
> 


-- 
Philippe.