All of lore.kernel.org
 help / color / mirror / Atom feed
From: Philippe Gerum <rpm@xenomai.org>
To: Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>,
	xenomai@xenomai.org
Subject: Re: [Xenomai] [Xenomai-git] Philippe Gerum : cobalt/posix: drop pthread_make_periodic_np/ wait_period_np services
Date: Mon, 16 Jun 2014 21:36:18 +0200	[thread overview]
Message-ID: <539F4732.5090100@xenomai.org> (raw)
In-Reply-To: <539F4283.8020602@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.
>

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.


  reply	other threads:[~2014-06-16 19:36 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <E1WwZye-0002zC-2B@sd-51317.dedibox.fr>
2014-06-16 19:02 ` [Xenomai] [Xenomai-git] Philippe Gerum : cobalt/posix: drop pthread_make_periodic_np/ wait_period_np services Gilles Chanteperdrix
2014-06-16 19:16   ` Philippe Gerum
2014-06-16 19:36     ` Philippe Gerum [this message]
2014-06-16 21:14     ` Gilles Chanteperdrix
2014-06-17  7:23       ` Philippe Gerum
2014-06-17  7:26         ` Gilles Chanteperdrix
2014-06-17  7:36           ` Philippe Gerum

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=539F4732.5090100@xenomai.org \
    --to=rpm@xenomai.org \
    --cc=gilles.chanteperdrix@xenomai.org \
    --cc=xenomai@xenomai.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.