Use sd-event instead of threads
Gamemode currently uses two threads, one for handling dbus and one for process reaping and config file watching. Because it's threaded, it also has a complex system of read/write locks to protect internal data structures. If a proper event loop were used instead of threads, the locking could be deleted and the whole thing would probably be a lot cleaner. Fortunately, systemd already provides an event loop called sd-event which has everything gamemode needs:
- sd-bus integration
- Timers
- Child process watching (for reaping)
- Inotify watching (for detecting config file changes)
It also properly uses poll so everything happens exactly on-demaind instead of having to wake up every 5s to look at file descriptors again. I started down this path when working on #179 but the refactor was quickly getting into yak shaving territory and so I put it down.
I meant to use pidfds (introduced with #173) for watching the processes in the daemon instead of the reaper thread. We can probably even get away by using plain epoll (plus timerfds) in the case people are concerned about gamemode tying itself even more to systemd.
Are people concerned about that? It's not like it actually requires systemd init. The whole reason why the the systemd people wrote sd-event was so that people would stop hand-rolling epoll loops.
Are people concerned about that? It's not like it actually requires systemd init. The whole reason why the the systemd people wrote sd-event was so that people would stop hand-rolling epoll loops.
I am surely not concerned about it :wink:, but I bet there are some. It seems like elogind has sd-event. I would hope that this should be good enough.