From: Jim Houston <jim.houston@attbi.com>
To: linux-kernel@vger.kernel.org, jim.houston@ccur.com
Subject: signal queue resource - Posix timers
Date: Wed, 28 May 2003 14:56:15 -0400 [thread overview]
Message-ID: <200305281856.h4SIuFZ02449@linux.local> (raw)
Hi Everyone,
In my continuing work to perfect posix timers, I have started thinking
about the problem of managing signal queuing resources.
The sigqueue structures used to queue siginfo_t structures are
allocated from a slab cache. The system limits this allocation to a
maximum of 1024 queued signals. This global limit means that
a process may fail at the whim of an unrelated process.
The attached test program easily consumes all of the available
sigqueue entries. It blocks SIGRTMIN and sends itself 2000 SIGRTMIN
signals. Running this program along with a posix timers test will
cause the posix timers to fail. Using realtime signals makes it easy
to consume this resource, but the failure could also occur with many
processes each having only a few pending signals.
Changing from a system wide limit to a per process limit would solve
most of this problem. It does not protect against having the allocation
from the slab cache fail. 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.
I'm contemplating changes to kernel/signal.c to allow reserved or
pre-allocated sigqueue structures to be used. The idea is to do the
allocation in the system call context so the failure can be returned to
the application.
In the pre-allocated approach, the timer code would allocate a sigqueue
structure as part of the timer_create. I would add new send_sigqueue() and
send_group_sigqueue() which would accept the pointer to the pre-allocated
sigqueue structure rather than a siginfo pointer. There would also be changes
to the code which dequeues the siginfo structure to recognize these
preallocated sigqueue structures. In the case of Posix timers using a
preallocated siqueue entry also makes handling overruns easier. If the timer
code finds that its sigqueue structure is still queued, it can simply increment
the overrun count.
The reservation approach would keep a pre-allocated pool of sigqueue
structures and a reservation count. The timer_create would reserve
a sigqueue entry which would be place in the pool until it is needed.
I wonder if anyone else is interested in this problem.
Jim Houston - Concurrent Computer Corp.
--
/*
* Example program which consumes all of the available sigqueue
* structures.
*/
#include <unistd.h>
#include <stdio.h>
#include <signal.h>
void handler(int sig, siginfo_t *info, void *context)
{
printf("handler called\n");
printf("si_signo=%d si_code=%d si_errno=%d\n",
info->si_signo, info->si_code, info->si_errno);
}
int main(int argc, char **argv)
{
struct sigaction sa;
sigset_t s;
int i, ret;
sa.sa_sigaction = &handler;
sa.sa_flags = SA_SIGINFO;
sigemptyset(&sa.sa_mask);
if (sigaction(SIGRTMIN, &sa, 0) != 0) {
perror("sigaction");
exit(1);
}
sigemptyset(&s);
sigaddset(&s, SIGRTMIN);
if (sigprocmask(SIG_SETMASK, &s, NULL) != 0) {
perror("sigprocmask");
exit(1);
}
for (i = 0; i < 2000; i++)
if ((ret = kill(getpid(), SIGRTMIN)))
break;
if (ret)
perror("kill");
sleep(5);
sigemptyset(&s);
if (sigprocmask(SIG_SETMASK, &s, NULL) != 0) {
perror("sigprocmask");
exit(1);
}
sleep(1);
return(0);
}
next reply other threads:[~2003-05-28 18:42 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-05-28 18:56 Jim Houston [this message]
2003-05-28 22:01 ` signal queue resource - Posix timers Ulrich Drepper
2003-05-28 23:14 ` Jim Houston
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=200305281856.h4SIuFZ02449@linux.local \
--to=jim.houston@attbi.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