>>78638>Aber dann mußt du erstmal herausfinden, welche Prozesse zu deinem User gehören und zu welcher Anwendung, und mit welchem du eigentlich sprechen willst.
Also dafür braucht man nun wirklich ein D-Bus. Einfach ein Socket in /run/user/1000 und gut. Macht D-Bus übrigens genauso:
ls -lah /run/user/1000
drwx------ 15 felix felix 340 Jul 29 16:41 .
drwxr-xr-x 3 root root 60 Jul 25 03:13 ..
drwx------ 2 felix felix 60 Jul 25 03:13 at-spi
srw-rw-rw- 1 felix felix 0 Jul 25 03:13 bus
drwx------ 3 felix felix 60 Jul 25 03:13 dbus-1
...
Meinetwegen. Aber wie oft braucht man Broadcasts und wozu? Wieviel Prozent von dem, was D-Bus so tut, ist Broadcasts und wieviel ist ganz normale, uni-/bidirektionale Kommunikation? Mir fällt ehrlich gesagt auch kein einziger Anwendungsfall für Broadcasts ein. Meine erster Gedanke war, wenn der Rechner in den Standby geht, oder der Benutzer sich ausloggt, oder wenn der Bildschirmschoner angeht. Aber das könnte man auch einfach lösen, indem die Shell bzw. der Bildschirmschoner ein Domänensocket anlegt, an dem sich dann jeder interessierte Prozess anmeldet. Was gäbe es noch? Ein USB-Gerät wurde an- oder ausgesteckt? Hier gilt das gleiche. Memory Pressure Events? Kann Linux bereits [0] und D-Bus wäre dazu aufgrund seines eigenen Overheads wohl auch nicht geeignet.
>>78639>- sagen, ob Messages angekommen sind
Dafür brauche ich kein D-Bus. Wenn der Prozess eine Nachricht erhalten hat, dann sendet er eine Antwortnachricht.
>- sich um Nebenläufigkeit kümmern
Hierfür brauche ich ebenfalls kein D-Bus. Sockets können Nebenläufigkeit schon von Haus aus.
[0] https://unix.stackexchange.com/a/434467