Display server main control loop

[Daniel van Vugt]

Yeah I agree any solution needs to replace the existing loop in 
DisplayServer::run(). We don't want two loops resembling a "main loop".

I'm still cautious about using the word "event" though. Maybe call these 
particular things "CoreEvent", or DisplayServer::Event's


On 02/04/13 20:40, Alexandros Frantzis wrote:
> 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
>