From: Jim Houston <jim.houston@attbi.com>
To: Ulrich Drepper <drepper@redhat.com>
Cc: linux-kernel@vger.kernel.org, jim.houston@ccur.com
Subject: Re: signal queue resource - Posix timers
Date: Wed, 28 May 2003 19:14:30 -0400 [thread overview]
Message-ID: <3ED542D6.795A7467@attbi.com> (raw)
In-Reply-To: 3ED531AD.1020309@redhat.com
Ulrich Drepper wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> > Posix timers are required to fail the
> > timer_create with EAGAIN if "the system lacks sufficient signal queuing
> > resources to honor the request." The current Linux posix-timers
> > implementation doesn't do this.
>
> That's not really how you can interpret this. At the time timer_create
> is it is not know when the timer expires and whether it's a repeating
> timer. Therefore it is not correct to assume that if timer_create
> succeeds the resources to always deliver the signal are available.
Hi Ulrich,
My intention is to allocate a sigqueue structure in the kernel as part
of the timer_create call. Later on in timer completion, I will use this
preallocated sigqueue entry to queue the siginfo_t for the timer completion.
The Posix timers specification guarantees that there can only be a single
signal pending for a given timer so preallocating one sigqueue structure
for each timer is sufficient.
Perhaps I should have tracked down the appropriate "shall deliver the
signal on timer completion" and quoted it instead. The point is that
the current Linux implementation will fail to deliver the signal at the
whim of other programs which might consume the limited signal queue
resource.
I saw your post on the posixtest-discuss which complained about the test suite
trying to force this condition. I agree that this is a bad test. When I preallocate
this resource, I may happily wait for a sigqueue entry to be available
and never return this failure.
Have a look at the Rationale and Notes section B.14.2.2 Create a Per-Process
Timer. It is fairly clear that it expects signal queuing resources to
be allocated at timer_create time and that failing to deliver a completion
signal is never acceptable.
Jim Houston - Concurrent Computer Corp.
next prev parent reply other threads:[~2003-05-28 23:01 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-05-28 18:56 signal queue resource - Posix timers Jim Houston
2003-05-28 22:01 ` Ulrich Drepper
2003-05-28 23:14 ` Jim Houston [this message]
2003-05-29 2:16 ` William Lee Irwin III
2003-05-29 1:46 ` William Lee Irwin III
2003-05-29 5:26 ` Ed L Cashin
2003-05-29 16:07 ` Timothy Miller
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=3ED542D6.795A7467@attbi.com \
--to=jim.houston@attbi.com \
--cc=drepper@redhat.com \
--cc=jim.houston@ccur.com \
--cc=linux-kernel@vger.kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox