Re: kqueue: SIGIO?

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

    Date:        Wed, 30 Sep 2015 00:30:36 +0200
    From:        Joerg Sonnenberger <joerg%britannica.bec.de@localhost>
    Message-ID:  <20150929223036.GA18661%britannica.bec.de@localhost>

  | If there is any kind of load going on,
  | the signal sending is more costly than occassional querying the kqueue
  | for (other active) entries.

You cannot possibly know that - it all depends upon the relative frequencies.

Without having any actual idea what the priorities are, I would assume the
aim is to optimise, as much as possible, the (relatively common, I'd expect)
situation where there's a single client hammering the server, and no other
activity at all (eg: a game playing, or video (mplayer, etc) output, in
fullscreen).

When that's the situation, doing anything at all other than processing the
client's requests is going to slow things down - and that includes 
"occasionally querying" or any other active activity.

The obvious problem, that they seem to be wanting to address is when they
have guessed incorrectly about the  situation, and there is another client
that is making (comparatively rare) requests, then if they concentrate on
the busy client the other gets starved.    For that, using signals looks
like a reasonable fit ... most of the time, when there is no other client,
the busy client isn't slowed at all (a signal that doesn't come costs zero),
but when there is that other client, they get informed, and can react,
without delaying that other client noticeably at all.

All that said, I'm not convinced that signals are the best solution - what
they may be (on some systems) is the only solution that is available now.
That is, doing it that way can work immediately, and does not require
kernel developers to change their kernels, nor users to upgrade their kernels
in order to run the improved X server.   For someone working with X a
solution like that is what they'd want to aim for.   It sounds as if on
linux (based purely on what I have read here) that is what happens.

On the other hand, if kernel changes would be needed (for example to make
SIGIO work with kqueue() on NetBSD) then we really should evaluate whether
or not there is a better change that could be made to handle the situation,
rather than just blindly making NetBSD the same as linux.   What that might
be though I have no idea.

Again, I'm guessing, but I'd assume that the server might be fetching requests
from a shared memory queue, performing them, and placing the results either
back into the client shared memory, or into memory that's being shared with
the hardware for display purposes.   That is, no system calls are being made,
by anyone, at all.   That would make it kind of difficult for the kernel to
inform the server that there's something else it should be looking at, in any
way other than a signal (or some other kind of trap - one could imagine
having a shared mem access fault - instead of a signal - to interrupt the
server and inform it to go check elsewhere, but I don't see that as an
improvement over signals, though it would at least occur at a more predictable
time and so perhaps reduce the need for internal locking operations in the
server).    Right now, aside from polling other events, which either adds
load when there are none - either noticeable load, or unacceptable delays
to the other client - I don't see an alternative to using signals.

But that doesn't mean there isn't one - perhaps there is some system call
that is being performed in even the tightest loop in the server's event
processing (that is, which is always performed) - where it might be
acceptable to pervert the result of that system call (like perhaps having
the underlying sys call for time() return EINTR or something) in a way
that the server could use to be notified, without adding any cost at all
when there is no notification.  Whether that would be better than just
using signals, I have no idea, but the possibilities, if there are any,
could at least be investigated.

kre