[PATCH xserver 23/24] Remove readmask from screen block/wakeup handler

[Mark Kettenis]

> From: Keith Packard <keithp at keithp.com>
> Date: Mon, 21 Sep 2015 12:06:22 +0100
> 
> Mark Kettenis <mark.kettenis at xs4all.nl> writes:
> 
> > This, of course, has impact on pretty much all the drivers.  Many use
> > compat-api.h and could probably be fixed by adding an additional
> > stanza there.  But somebody still needs to do that work.
> 
> A few actually use the block and wakeup handlers to manage additional
> file descriptors, and those will take actual work to change them to use
> the new NotifyFd interface.
> 
> Most of the compat-api.h versions I see already contain
> BLOCKHANDLER_ARGS, and a few contain WAKEUPHANDLER_ARGS as well, so at
> least a few drivers will make this pretty easy to manage.

In the OpenBSD xenocara tree, only the xf86-video-ati and
xf86-video-intel drivers actually use the handlers to manage
additional file descriptors.  However there are 35 copies of
compat-api.h in or tree that would need to be updated.

As with all driver API changes I question whether the urge to clean up
APIs should win from keeping the API compatible in the xserver code
base.  One could for example simply pass NULL in the last argument of
the block and wakeup handlers.  That would weed out drivers that use
the argument quickly enough (but admittedly would not guarantee that
such all such usage would be caught).

> I'm still fumbling around creating a suitable way for the OS layer to
> use epoll, kqueue or poll as an appropriate replacement for select. I
> hope I'm getting closer though; something much like the NotifyFd
> interfaces might work. With that, we'll be able to actually connect
> MAXCLIENTS to the server, even with input devices, system interface
> libraries and listening sockets occupying some of the file descriptor
> space.

Replacing select with poll seems a useful goal indeed.  I'm not so
sure about epoll and kqueue as they're not portable.  You'd end up
with separate code paths that would both have to be tested, and you'd
probably need even more to support Solaris and Windows.  And then
there are those damn corner cases where each system behaves in a
slighly different buggy way.  But perhaps a well-tested framework like
libevent could remove that headache.