Reactiveness

The window manager should at all stages be reactive and only use a minimal amount of resources. In order to assure this polling of threads should never be implemented.

Event Sources

Events for the window manager can be created by multiple sources.

  1. X-Events Generated by the X-Server and regarding userinput, clients requests and more.

  2. IPC-Events Generated via the IPC-mechanism by the user or programs running on the system.

In order to be able to handle these two event sources two possible solutions are available:

  1. Polling of both event-sources

poll for X-Event
poll for IPC-event
execute received event

This layout allows for a very simple single threaded implementation of the window manager but requires a frequent polling loop in order to allow for a reactive behavior.

Therefore this layout is not suitable for our requirements as this would be very inefficient.

  1. Multithreaded queues

../../_images/ipc_queue.png

IPC-queue

This layout requires three different queues. 1. X-Event queue -> waits until an x-event is received 2. IPC-Event queue -> waits until an IPC-event is reveived 3. mainloop -> waits for an event forwarded to the mainevent-queue by the above mentioned threads

If implemented in the above shown way, no polling is required. This therefore allows to sleep the threads until an event is received and the kernel wakes up the thread. It therefore will be very reactive and use only minimal resources.

=> Therefore we will implement this layout.

Technical solution

Waiting for event

The following documents functions of the chosen libraries that support waiting for an event:

  1. X-Event The x11rb library supports waiting on an event: wait_for_event method

  2. IPC-Event Zbus is asynchronous in nature. The handling functions are registered to the server and executed when an event is received. Zbus Example

  3. mainloop as shared queue the channel implementation of the rust standard library was chosen. This allows to wait for an event: recv method