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?
Thx for your patience!
Klaas
_______________________________________________
Xenomai-help mailing list
[email protected]
https://mail.gna.org/listinfo/xenomai-help
