Re: [Xenomai-help] rt_task_wait_period returns an undocumented value

[Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>]

On 10/21/2011 07:37 PM, Fernando Herrero Carrón wrote:
> El 21 de octubre de 2011 14:15, Gilles Chanteperdrix <
> gilles.chanteperdrix@xenomai.org> escribió:
> 
>> On 10/21/2011 06:04 PM, Fernando Herrero Carrón wrote:
>>> Dear list,
>>>
>>> I am running xenomai-2.6-rc4 on an amd64 linux kernel version 2.6.38.8.
>>>
>>> I am setting up a periodic task using
>>>
>>> rt_task_set_periodic(NULL, TM_NOW, 11500);
>>>
>>> For period values smaller than 11450 I get an EINVAL return value. I've
>> got
>>> one question regarding this, and it's how is this threshold calculated?
>>
>> See:
>>
>> http://www.xenomai.org/documentation/trunk/html/api/group__pod.html#gaed5776a428e7c59b52b1da76f0d765fa
>>
> 
> Hmm, that doesn't make very clear why some values for "period" are accepted
> and some others are not. Are they fixed? Are they calculated based on some
> system-dependent calibration procedure?

Summarized version: "-EINVAL is returned if (...) period is different
from TM_INFINITE but shorter than the scheduling latency value for the
target system, as available from /proc/xenomai/latency"

I do not see how it could be made more clear.

> 
> 
>>>
>>> However, further down the program, supposing rt_task_set_periodic()
>> failed
>>> with the above result, calling
>>>
>>> rt_task_wait_period()
>>>
>>> will return EAGAIN, which is not documented in
>>>
>> http://www.xenomai.org/documentation/trunk/html/api/group__task.html#ga1645d3a072ef3cefeed3bcbb27dcf108
>>> .
>>
>> That is because glibc choose to have EWOULDBLOCK == EAGAIN. And
>> EWOULDBLOCK is documented.
>>
>>
> Ok, I see. This seems a bit confusing to me. What would happen if someone
> were using a different libc than glibc? If the code is using EWOULDBLOCK all
> over the place then that's fine.
> 
> Finally, what do you think of extending:

I find the current version perfectly clear and find no reason to extend
it this way. Having called a function which failed should be equivalent
to not having called the function, in any reasonable API.

Not checking services return values, and continuing anyway in case of
error is a bad programming habit, especially when writing "critical" code.

-- 
					    Gilles.