mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
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.

             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