Please help with signals, some seem to get lost

[Erik Slagter]

Hi Thiago,

Thank you very much for your interest!

I will include a piece of dbus-monitor output here to hopefully answer 
some of your questions. Please note that consistently all sent signals 
are shown in the output, so I like to assume that the problem is on the 
receiving side. I left out the actual payload data because it's not 
really human readable.

-------------------------------- >-8 --------------------------

signal time=1736793922.320478 sender=:1.20990 -> destination=(null 
destination) serial=98 path=/name/slagter/erik/espproxy; 
interface=name.slagter.erik.espproxy.signal.esp8266.display.graphic; 
member=push_command string "..." (~400 bytes of opaque data)

signal time=1736793922.321147 sender=:1.20990 -> destination=(null 
destination) serial=99 path=/name/slagter/erik/espproxy; 
interface=name.slagter.erik.espproxy.signal.esp8266.display.graphic; 
member=push_command string "..." (~400 bytes of opaque data)

signal time=1736793982.495803 sender=:1.20991 -> destination=(null 
destination) serial=95 path=/name/slagter/erik/espproxy; 
interface=name.slagter.erik.espproxy.signal.esp8266.display.graphic; 
member=push_command string "..." (~400 bytes of opaque data)

signal time=1736793982.496052 sender=:1.20991 -> destination=(null 
destination) serial=96 path=/name/slagter/erik/espproxy; 
interface=name.slagter.erik.espproxy.signal.esp8266.display.graphic; 
member=push_command string "..." (~400 bytes of opaque data)

signal time=1736793982.496299 sender=:1.20991 -> destination=(null 
destination) serial=97 path=/name/slagter/erik/espproxy; 
interface=name.slagter.erik.espproxy.signal.esp8266.display.graphic; 
member=push_command string "..." (~400 bytes of opaque data)

-------------------------------- >-8 --------------------------

ES> For my application I need to send signals to several listeners on the
ES> system bus. The signals are composed of a string of about 300 bytes.
ES> Sometimes some signals are sent in quick succession and that's where it
ES> goes wrong.

> Are they directed signals? That is, do they have a destination bus address
> set?

I just learned about this option yesterday, as a warning to avoid that 
(apparently such messages are prone to be discarded). so I guess, no 
;-). The targeted "interface" is 
"name.slagter.erik.espproxy.signal.esp8266.display.graphic"

ES> dbus_connection_read_write_dispatch(connection, -1)
ES> message = dbus_connection_pop_message(connection)
ES>
ES> Now every now and then dbus_connection_read_write_dispatch returns from
ES> blocking but dbus_connection_pop_messages returns NULL.

> That's normal. It dispatches one read OR write. If it did the latter, then
> there is no message to be popped.

Okay, I had this hunch already. So I changed the code to repeatedly call 
both methods until an actual message is received and report when the 
first method returns but no message could be popped. Now it gets 
interesting I think: the total amount of the first method 
(dbus_connection_read_write_dispatch) returning is exactly the same on 
all listening clients. Just, randomly distributed over the listening 
clients, one or more instances do not yield to a pop-able message. 
Please see this debug output to see what I mean. Please also note (see 
dbus-monitor output) I am sending 5 signals and only 4 are received 
(this is consistent).

-------------------------------- >-8 --------------------------
an 14 10:12:11 artemis espif[2789853]: signal received, interface: 
name.slagter.erik.espproxy.signal.esp8266.display.graphic, method: 
push_command
jan 14 10:12:11 artemis espif[2789853]: signal received, interface: 
name.slagter.erik.espproxy.signal.esp8266.display.graphic, method: 
push_command
jan 14 10:12:11 artemis espif[2789853]: signal received, interface: 
name.slagter.erik.espproxy.signal.esp8266.display.graphic, method: 
push_command
jan 14 10:12:11 artemis espif[2789853]: signal received, interface: 
name.slagter.erik.espproxy.signal.esp8266.display.graphic, method: 
push_command

***

jan 14 10:12:11 artemis espif[2789855]: signal received, interface: 
name.slagter.erik.espproxy.signal.esp8266.display.graphic, method: 
push_command
jan 14 10:12:11 artemis espif[2789855]: signal received, interface: 
name.slagter.erik.espproxy.signal.esp8266.display.graphic, method: 
push_command
jan 14 10:12:11 artemis espif[2789855]: no messages in queue, attempt: 0
jan 14 10:12:11 artemis espif[2789855]: signal received, interface: 
name.slagter.erik.espproxy.signal.esp8266.display.graphic, method: 
push_command
-------------------------------- >-8 --------------------------

ES> Two interesting observations here:
ES> - other processes that are listening to the same signal do get the
ES> message indeed, it's just one (random) of them that gets the NULL 
message

> It probably was sending something before that. Call it again, because after
> all this function is meant to be used in a loop, as its documentation shows:
> https://dbus.freedesktop.org/doc/api/html/
> group__DBusConnection.html#ga580d8766c23fe5f49418bc7d87b67dc6

How do you mean exactly? "It" is the client I assume? The client is not 
really sending things, it is only responding to one type of method call, 
which works without any issue and is fully completed before the signals 
are received. After sending the reply I do a dbus_connection_flush(), 
should I add a call to dbus_connection_read_write_dispatch there 
(after/before?).

> There isn't a rate limiter.

So it's a race condition ;-) Now just find out where it is...