Display server main control loop

[Alexandros Frantzis]

Hi all,

while working on adding VT switching I noticed that the code started to
become more complicated, as I needed to handle asynchronous events (a
signal in this case) and coordinate cross-component operations.

One way to improve the situation is to add a main control loop to the
display server. This is *not* meant to be a loop for all kinds of events
(e.g.  input, graphics), only for external asynchronous events that need
to change the state of the main components of the display server in a
coordinated manner.

Such events are:

* Quitting (signals)
* VT switching (and more generally, display server pause/resume) (signals)
* Display reconfiguration (e.g. watching a udev FD on the desktop)

Although, we could conceivably handle these in a distributed manner, I
feel we would be adding a lot of complexity and fragility to the system.

There are a couple of mechanisms we could use to implement a main
control loop and that could handle events from all our sources (signals
and FDs for now).  We could use boost asio, or we could implement our
own mechanism, using signalfd to route the signals to an fd we can
select() on.

The main loop could live in the DisplayServer::run() method, replacing
the wait on the exit_cv condition variable that is currently there, or
it could run in a separate thread like SignalDispatcher currently does.
I prefer the first approach since the main display server thread is idle
anyway, and it's a natural place for such an event loop.

Thoughts? Any other events of this kind that we should be aware of?

Thanks,
Alexandros