Re: kqueue: SIGIO?

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    Date:        Wed, 30 Sep 2015 09:45:32 -0400
    From:        Thor Lancelot Simon <tls%panix.com@localhost>
    Message-ID:  <20150930134532.GA25654%panix.com@localhost>

  | Does the problem actually have to do with the mouse and keyboard?

The server also needs to deal with (potential) network connections from
clients - most people these days might only run clients on the same system
as the server, and so can use shared mem, but not everyone is so limited
(I know I run across-net connections, even if it is just from a xen DomU
client to the X server running on the Dom0 - but I also do real over
ethernet/wireless X connections too on occasion).   Those connections
will never be the high performance kind, but nor should they be starved
by some other local high performance shared-mem using local client.

  | Mouse's idea of having the kernel
  | write a flag word instead of interrupting the process seems like a 
  | very nice fit if so.

It also fits with the only safe thing that's really possible to do in a
single handler being to set a variable and return (or exit the process)
(ie: the main loop has to check a variable anyway, whether signal delivery
is traditional, or via Mouse's suggested mechanism).

The issue with it is how one would ever safely clear the variable again,
while avoiding race conditions - when a signal handler sets the variable,
it is all user code, and can use locking to be safe, one cannot lock out the
kernel though.   But maybe, given this is supposed to be rare, a sys call
to clear the var, after detecting it set, would be acceptable - or just
switch to a different var for subsequent notifications using the original
sys call, after which the first one is just a variable again, and can be
cleared normally (though that would require an indirect reference to
check it, and so greater cost for that.)

kre