Today, the systemd project uses a non-standard superset of C to get destructor-like functionality. But, we pay a heavy price for doing it this way: we lose compiler portability, use hundreds of boilerplate macros, and confuse static analysis tools (which don't always realize why we're not leaking memory). At compilation, the cleanup functionality gets mapped to the same facilities that handle C++ destructors. So, essentially, we're already using a non-standard version of C++ as well as a non-standard version of C. We can end this charade by following in GCC's footsteps and explicitly using a subset of C++. By doing so, we can shed thousands of lines of C-trying-to-be-C++. We can also improve memory safety and code readability -- all while keeping the feel of C.
\n\nIn this presentation, we'll consider options for systems'd codebase:
\nWhen configuration changes, daemon-reload stops the world in an increasingly unsustainable way. The problem is getting worse for two reasons: (1) heavier use of systemd means more units and longer reload times and (2) expanded use of socket activation/D-Bus activation/automount means more things urgently need PID 1's attention. There are ways to fix this up, but we'll need to move away from stopping the world (the main event loop), throwing out most loaded state, reloading state, and then resuming event handling.
\n\nWe'll explore these options:
\nWe'll need to be careful to maintain the memory footprint on resource-constrained devices, but we have options:
\n