Re: kqueue: SIGIO?

[Mouse <mouse%Rodents-Montreal.ORG@localhost>]

>> Mouse's idea of having the kernel write a flag word instead of
>> interrupting the process seems like a very nice fit if so.
> The issue with it is how one would ever safely clear the variable
> again, [...]

This is not difficult: you do it by not clearing the variable.

For the sake of argument and brevity, let us suppose a suitable type
for the variable in question is unsigned int.  Then the kernel, instead
of _setting_ the variable, can _increment_ the variable, and userland
can do something like

volatile unsigned int sigflag;
unsigned int chksigflag;
unsigned int lastsigflag;

sigflag = 0;
lastsigflag = 0;
handle_via_flag_variable(SIGIO,&sigflag); // flag to sigaction()?
while (1) { // main loop
	...
	chksigflag = sigflag;
	if (chksigflag != lastsigflag) {
		lastsigflag = chksigflag;
		...handle the signal...
	}
	...
}

Obviously, there is still a potential issue; if the kernel delivers
exactly k*2^32 (for integer k, assuming 32-bit unsigned ints) signals,
between userland checks, userland will miss them.  I don't consider
this a big enough risk to worry about; if it really bothers you, make
it long long int instead - there is some risk of value tearing in the
read on many architectures, but, since the kernel's increment is atomic
with respect to userland, the worst it will do is delay noticing the
signal by one trip around the loop.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		mouse%rodents-montreal.org@localhost
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B