tl;dr: Use gss_service_hold() and gss_service_release() from libgsystemservice.
Automatically shutting down daemons when not in use is in vogue, and a good way of saving resources quite easily (if the service’s startup/shutdown costs are low).
libgsystemservice can do this for you automatically, if your code is based on GssService, or if you want to port over to it (which should be fairly straightforward for simple services). It supports inactivity timeouts by default; just call gss_service_hold() when you start doing some activity, and gss_service_release() when you stop.
(Also, look, it’s neat that you can generate documentation and automatically publish it from your master branch using GitLab CI!)
Oooh, nifty! Finally some code for https://wiki.gnome.org/Design/Whiteboards/BackgroundApps - Geary could use something like this for it's quit-and-stay-resident mode.
Isn't libgsystemservice just for the system bus though?
libgsystemservice is intended for the system bus, yes. It provides various things which don’t make sense on a session bus. Without knowing anything about the design for quit-and-stay-resident mode in Geary, I can’t confidently suggest the right approach, but from reading that wiki page I suspect it would be appropriate to extend `GtkApplication` to support this.
It might make sense to extend libgsystemservice to support session daemons, but only ones which never show a window (i.e. they are designed as a daemon, not an app). If someone wants to open an issue about that (https://gitlab.gnome.org/pwithnall/libgsystemservice/issues), it could be discussed there.
I had the idea of a daemon which loads many tasks in form of shared libs and is controlled by dbus. This way writing daemons is straightforward (just writing a plugin) and saves a lot of memory (by unloading if the task is finished+no own daemon routines)
Because there are not many context switches (no signals, no processes) in my proposed solution it would probably be much faster. But... no time.
You need separation between processes to get isolation of the security domains of the different tasks. Your idea would only work if all the tasks could be mutually trusted to access each others’ data.