From: linux@horizon.com
To: linux-kernel@vger.kernel.org, tytso@mit.edu
Cc: linux@horizon.com
Subject: Re: A better interface, perhaps: a timed signal flag
Date: 29 Jul 2006 02:56:12 -0400 [thread overview]
Message-ID: <20060729065612.8661.qmail@science.horizon.com> (raw)
> If we had such an interface, then the application would look like
> this:
>
> volatile int flag = 0;
>
> register_timout(&time_val, &flag);
> while (work to do) {
> do_a_bit_of_work();
> if (flag)
> break;
> }
>
> Finally, a note about tickless designs. Very often such applications
> don't need a constantly ticking design. For example, the X server
> only needs to have the memory location incremented while it is
> processing events; if the laptop is idle, there's no reason to have
> the RTC generating interrupts and incrementing memory locations.
> Similarly, the Metronome garbage collector would only need to poll to
> see if the timeout has expired while the garbage collector is running,
> which is _not_ all of the time.
>
> Yes, you could use ioctl's to start and stop the RTC interrupt
> handler, but that's just ugly, and points out that maybe the interface
> should not be one of programming the RTC interrupt frequency directly,
> but rather one of "increment this flag after X units of
> (CPU/wallclock) time, and I don't care how it is implemented at the
> hardware level."
Actually, unless you want the kernel to have to poll the timeout_flag
periodically, it's more like:
volatile bool timeout_flag = false, armed_flag = false;
register_timout(&time_val, &flag);
while (work to do) {
if (!armed_flag) {
rearm_timeout();
armed_flag = true;
}
do_a_bit_of_work();
if (timeout_flag) {
armed_flag = false;
timeout_flag = false;
break;
}
}
Personally, I use setitimer() for this. You can maintain the flags in
software, and be slightly lazy about disarming it. If you get a signal
while you shouldn't be armed, *then* disarm the timer in the kernel.
Likewise, when rearming, set the user-disarmed flag and chec if kernel-level
rearming is required.
volatile bool timeout_flag = false, armed_flag = false, sys_armed_flag = false;
void
sigalrm(int sig)
{
(void)sig;
if (!armed_flag) {
static const struct itimerval it_zero = {{0,0},{0,0}};
if (sys_armed_flag)
warn_unexpected_sigalrm();
setitimer(ITIMER_REAL, &it_zero, 0);
} else if (timeout_flag)
warn_gc_is_slow();
else
timeout_flag = true;
}
void
arm_timer()
{
static const struct itimerval it_interval = { time_val, time_val };
armed_flag = true;
if (!sys_armed_flag) {
setitimer(ITIMER_REAL, &it_interval, 0);
sys_armed_flag = true;
}
}
main_loop()
{
signal(SIGALRM, sigalrm);
while (work to do) {
arm_timer();
do_a_bit_of_work();
if (timeout_flag) {
gc();
armed_flag = false;
timeout_flag = false;
}
}
}
... where only do_a_bit_of_work can prompt the need for more gc() calls.
This really tries to minimize the number of system calls.
next reply other threads:[~2006-07-29 7:53 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-07-29 6:56 linux [this message]
[not found] <fa.xkoDc6Uvpcp6dnG8+9iwy53PPeo@ifi.uio.no>
[not found] ` <fa.7gpoVg9wmtQ0g4u4T8FaCZGXup0@ifi.uio.no>
2006-07-29 18:29 ` Robert Hancock
-- strict thread matches above, loose matches on Subject: below --
2006-07-26 15:15 Brown, Len
2006-07-25 19:47 [PATCH] RTC: Add mmap method to rtc character driver Neil Horman
2006-07-25 20:04 ` Dave Airlie
2006-07-25 20:24 ` H. Peter Anvin
2006-07-25 20:47 ` Neil Horman
2006-07-25 20:50 ` H. Peter Anvin
2006-07-25 22:25 ` Neil Horman
2006-07-25 23:29 ` Segher Boessenkool
2006-07-25 23:56 ` Neil Horman
2006-07-26 0:02 ` H. Peter Anvin
2006-07-26 0:20 ` Neil Horman
2006-07-26 14:45 ` A better interface, perhaps: a timed signal flag Theodore Tso
2006-07-28 13:33 ` Steven Rostedt
2006-07-28 14:52 ` Theodore Tso
2006-07-28 15:05 ` Steven Rostedt
2006-07-28 16:41 ` Alan Cox
2006-07-28 16:44 ` Steven Rostedt
2006-07-28 20:01 ` Alan Cox
2006-07-28 20:12 ` Steven Rostedt
2006-07-28 20:36 ` Alan Cox
2006-07-28 20:31 ` Steven Rostedt
2006-07-28 17:11 ` H. Peter Anvin
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=20060729065612.8661.qmail@science.horizon.com \
--to=linux@horizon.com \
--cc=linux-kernel@vger.kernel.org \
--cc=tytso@mit.edu \
/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
Powered by JetHome