Input handlers date back to early versions of WINGs. They provide
a way to listen for state changes on file descriptors (including
networking sockets) as part of the WINGs event loop.
This functionality is not actually used in the Window Maker source
tree. It may have been more useful in the past, when WINGs provided
a networking socket API. The status quo appears to be that this is
largely dead code. Pumping the X11 event queue is special-cased in
the input handling code, so it can stay in for now.
This is an intermediate step in the process of dropping input FD
polling entirely (except for pumping the X11 event queue).
There is code to use poll(2) instead of select(2) to wait for events
on file descriptors (which includes waiting for events from the X11
event queue). It appears not to have been used in quite some time,
or perhaps never, as it contains a typo (`poll fd` instead of `pollfd`
on its first line).
To reduce code bloat and make source code easier to navigate, it
makes sense to prefer only one of these codepaths.
After correcting this typo, waiting for X11 events appears to work, so
the poll(2)-based code seems to be good enough. Keeping the poll-based
code is vaguely preferable because poll(2) has a slightly better
interface than select(2), and poll(2) has been a standard Unix API
for 30 years.
Since this code is slated to be replaced, the decision to use the
poll(2)-based code here is probably not very important. But future
programmers may want to use this as a branching-off point for switching
to epoll(7) or some other, less-select(2)-like interface.
This function requires tracking an explict client data pointer, which it would be preferable not to have in the Rust rewrite.
Removing this function entails tracking timer handlers explicitly, but this is not an undue burden.
