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.
_______________________________________________
Xenomai-help mailing list
[email protected]
https://mail.gna.org/listinfo/xenomai-help
