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

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

[Gilles Chanteperdrix]

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.


-- 
                                                                Gilles.

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

[Philippe Gerum]

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.

-- 
Philippe.

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

[Philippe Gerum]

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.
>

FWIW, this hint is also aimed at applications which insist on 
implementing their own threaded software timer subsystem. This pattern 
is typically found in legacy telecom software running over traditional 
embedded RTOSes, which tend to instantiate a truckload of threads, each 
one serving a particular periodic source. In that case, mentioning 
timerfd + select may help decreasing the level of non-sense, without 
having to change the basic pattern.

-- 
Philippe.

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

[Gilles Chanteperdrix]

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.

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

[Philippe Gerum]

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@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?

-- 
Philippe.

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

[Gilles Chanteperdrix]

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@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.

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

[Philippe Gerum]

On 06/17/2014 09:26 AM, Gilles Chanteperdrix wrote:
> 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@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.
> +**********************************************************************
>
>

There is no mention of the timerfd+read combo in this excerpt, what is 
mentioned is including a timerfd in synchronous multiplexing of multiple 
event sources. You seem to choke on "Alternatively", which is 
misleading, in should read "In addition" or something along. I'll fix this.

-- 
Philippe.