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

Gilles Chanteperdrix gilles.chanteperdrix at xenomai.org
Tue Jun 17 09:26:10 CEST 2014


On 06/17/2014 09:23 AM, Philippe Gerum wrote:
> On 06/16/2014 11:14 PM, Gilles Chanteperdrix wrote:
>> 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 at 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.
>>
> 
> Which documentation mentioning select + read are you referring to?
> 
+- `pthread_make_periodic_np()` and `pthread_wait_np()` have been
+removed from the API.
+
+.Rationale
+**********************************************************************
+With the introduction of services to support
+<<real-time-signals,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.
+**********************************************************************


-- 
                                                                Gilles.




More information about the Xenomai mailing list