On Mon, Nov 26, 2018 at 9:59 AM Tomasz Kłoczko <kloczko.tomasz@xxxxxxxxx> wrote: > 1) if dbus service crashes/is not availaible temporary IMO it wold be > good to prepare whole desktop apps code to not crash but handle dbus > disconnection and maybe display centered message that it is not > possible to connect to dbus. Crashing everything looks really *bad*. The design of D-Bus is that it is the central point of lifecycle management for your desktop - when the session bus goes away, everything on it should go away. Trying to make things survive bus restart compromises that, and makes it more likely you'll get stray processes after exit. Now with systemd user sessions, cgroups, etc, we have other mechanisms for session cleanup, but removing the older concept of exit-with-the-bus would require major rethinking. Plus, when the connection to the bus is lost, all assumptions that the app has about the state of the system are invalid. (Normally, with D-Bus you reliably get messages, or you reliably get notification when your communication partner goes away.) So the app state needs to be reinitialized from scratch. There's significant code complexity there which will be exercised in only very rare circumstance. In general, I don't think being able to replace the bus implementation on a running system is *that* interesting - sometimes the user will have to reboot, and if that's too disruptive, we need to work on making it less disruptive. Owen _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
