Re: [Xenomai] [Xenomai-git] Philippe Gerum : cobalt/posix: drop pthread_make_periodic_np/ wait_period_np services

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

On 06/16/2014 09:16 PM, Philippe Gerum wrote:
> On 06/16/2014 09:02 PM, Gilles Chanteperdrix wrote:
>> On 06/16/2014 06:41 PM, git repository hosting wrote:
>>> Module: xenomai-forge
>>> Branch: next
>>> Commit: a4a6ff9a9c9614d3e8ac860386fa3b168c649af0
>>> URL:    http://git.xenomai.org/?p=xenomai-forge.git;a=commit;h=a4a6ff9a9c9614d3e8ac860386fa3b168c649af0
>>>
>>> Author: Philippe Gerum <rpm@xenomai.org>
>>> Date:   Mon Jun 16 18:39:44 2014 +0200
>>>
>>> cobalt/posix: drop pthread_make_periodic_np/wait_period_np services
>>>
>>> We have no more in-tree users of these calls.
>>>
>>> With the introduction of services to support real-time signals, those
>>> two non-portable calls have become redundant. Instead, Cobalt-based
>>> applications should create a periodic timer using the timer_create()
>>> call, and wait for release points via sigwaitinfo(), checking for
>>> overruns by looking at the siginfo.si_overrun field.
>>>
>>> Alternatively, applications may include a timer source in a
>>> synchronous multiplexing operation, by passing a file descriptor
>>> returned by the timerfd() service to a select() call.
>>
>> Actually, read is more direct than select + read, and it allows to get
>> the count of overruns too.
>>
>>
> 
> As mentioned in the log, the illustration given is about synchronous 
> multiplexing, e.g. waiting for a release point in a timeline _and_ other 
> I/O event at the same time, not about single-sourced wait on a timer. 
> Otherwise you would just don't care a dime about using select(), I guess.
> 
timerfd_create / read is a strict replacement for
pthread_make_periodic_np/pthread_wait_period_np. Adding a call to select
simply adds some overhead that was not here in the first place. It
should be made clear in the documentation that calling select is not
necessary, otherwise users reading the documentation may assume that
they have to call select, and suddenly observe a larger latency and at
best complain, or at worst decide to stay with the old API.

-- 
                                                                Gilles.