Hi Brian, On 08/29, Gix, Brian wrote: > That is true, and we *expect* applications that are attached to handle > the socket-signals (that drive d-bus) in a timely manner... But I am > not sure we have a way to enforce it. > > Certainly, we can simulate a disconnection if an App ignores it's DBus > socket signal, but again, we won't know about that for 30 seconds > which seems like forever... And an App could potentially have a large > enough backlog of messages negatively affecting the daemon before it > and corrects it. This seems like a limitation of ELL: 1. There doesn't seem to be an explicit API to set timeouts on method calls, so if the application takes too long to handle method calls, message_list hashmap in l_dbus struct would indeed grow quite large. 2. There doesn't seem to be a way to set an upper limit of pending messages (or maybe even message rate?) in l_dbus connection. Still, looking at ell/dbus.c, it seems it should be possible to manually call l_dbus_cancel after obtaining serial number of the method call message, using _dbus_message_get_serial from dbus-private.h (yeah, I know). Anyway, I think a better approach would be to submit patches to ELL implementing these two features, and then use these additions in meshd. Does that sound acceptable from your POV? By the way, it seems that bluetoothd suffers from the same problem with regards to external GATT services/characteristics/descriptors. regards -- Michał Lowas-Rzechonek <michal.lowas-rzechonek@xxxxxxxxxxx> Silvair http://silvair.com Jasnogórska 44, 31-358 Krakow, POLAND
