Hi Daniel,

I dug up more relevant commits that explains this matter a bit.

2012-02-20 Patrik Flykt 1af75231e5cfaad061b9a2f58589b3fb6f37fd2e [1]:
 > service: Implement ServicesAdded and ServicesRemoved signals
 >
 > When services are added or removed, collect them into separate
 > lists in order to send as many as possible in one go and with
 > then removed ones sent first. Add a wait of 100ms to collect
 > more services in one batch. When removing a service check
 > whether it was also on the added list; if so, remove it from
 > that list.

^ This commit added that weird 100 ms timeout for sending signals.

2012-04-03 Patrik Flykt 365528e5155e1a1efe4aa81018d99502aaaf8558 [2]:
 > service: Add ServicesChanged signal
 >
 > Send ServicesChanged signal instead of consecutive ServicesAdded and
 > ServicesRemoved signals.

2012-08-20 Patrik Flykt 83cab654f1f78d49bd848b87cea645078f82f13e [3]:
 > service: Send updated properties after ServicesChanged
 >
 > Updated service properties are not sent before the new service
 > has been announced in a 'ServicesChanged' signal.

^ This commit added that allow_property_changed gate that causes 
PropertyChanged signals within 100 ms to be thrown away.

2015-08-12 Patrik Flykt 22d4605ae647db5d90c88d9f66164c66867334ed [4]:
 > service: Do not send PropertyChanged signals before service is
 > announced
 >
 > Send no service PropertyChanged signals before the service is
 > announced in ServicesChanged. Move the ServicesChanged adding right
 > after registering a service to D-Bus, as any ipconfig state updates in
 > between caused service PropertyChanged signals to be sent as the
 > service was missing from the new services hash for ServicesChanged
 > signal.

^ This commit moved `service_schedule_added` in 
`__connman_service_create_from_network` *after* autoconnect (now 
trigger_autoconnect). If I revert this change, the PropertyChanged 
signals that I miss are sent.


 > Not really sure how to address this though. Maybe do not call
 > service_schedule_changed() in __connman_service_create_from_network()
 > and instead send the ServiceChanged first?
Does this effectively mean remove the 100 ms timeout and send 
ServicesChanged right away?


I’m beginning to think that throwing away the PropertyChanged signals 
within 100 ms wasn’t the original intention. It’s a result of two 
requirements that are implemented in a contradictory way:

1. Don’t send ServicesChanged right after each change, but aggregate the 
changes within 100 ms interval and order service removals first.
2. Avoid sending PropertyChanged for a service before the 
ServicesChanged signal with this service listed is sent.

I would start by asking if both of these requirements are still valid.
Why sending PropertyChanged before the service is announced in 
ServicesChanged is a problem?

If these two requirements still apply, what about postponing 
PropertyChanged instead of throwing them away, i.e. accumulate them in a 
queue and send after the related ServicesChanged is sent?

Jakub

[1]: 
https://git.kernel.org/pub/scm/network/connman/connman.git/commit/?id=1af75231e5cfaad061b9a2f58589b3fb6f37fd2e
[2]: 
https://git.kernel.org/pub/scm/network/connman/connman.git/commit/?id=365528e5155e1a1efe4aa81018d99502aaaf8558
[3]: 
https://git.kernel.org/pub/scm/network/connman/connman.git/commit/?id=83cab654f1f78d49bd848b87cea645078f82f13e
[3]: 
https://git.kernel.org/pub/scm/network/connman/connman.git/commit/?id=22d4605ae647db5d90c88d9f66164c66867334ed