dbus activation on signal
Simon McVittie
simon.mcvittie at collabora.co.uk
Thu Mar 19 04:01:36 PDT 2015
On 19/03/15 10:27, WaLyong Cho wrote:
> As I knew, dbus auto activation is only working for method call and
> signal what has destination. But generally, in case of signal, the
> signal destination is not of listener(what hope to be activated).
Correct. D-Bus does not have a facility for services to be activated
automatically as a result of a broadcast signal.
If it did, there are some nasty ordering constraints - I certainly
wouldn't want to have to delay delivery of a broadcast until all
interested services had started up! - so I don't think adding this
feature would be a good idea.
> If dbus has no solution for this and it is not acceptable functionality,
> make a new daemon. The new daemon will listen all of signals and a
> special signal was sent then activate a set of other processes.
> But when the activated process can not receive the signal. Because that
> already sent in the past.
This approach is certainly one possibility.
If your D-Bus API is such that the activated process can perform state
recovery, then there's no problem. For instance, suppose you want to
start an activated service whenever the networking service
(NetworkManager or ConnMan or similar) detects a wireless network, which
does something on all the wireless networks.
On startup, the activated service should connect to the
NewWirelessNetwork signal (or whatever your networking service calls
it), but ignore it if received; then call GetAllWirelessNetworks to see
what is currently available; then on receiving the reply to
GetAllWirelessNetworks, behave as if all those networks had just been
detected, and stop ignoring NewWirelessNetwork.
If you don't or can't do state-recovery, then in general your system is
broken *anyway*, because you might miss a wireless network that appears
after you have started up, but before you have connected to the
NewWirelessNetwork signal.
The same applies to any other (signal, state-recovery method) pair.
S
--
Simon McVittie
Collabora Ltd. <http://www.collabora.com/>
More information about the dbus
mailing list