On Apr 11, 2020, at 9:00 AM, Denis Kenzior <denkenz(a)gmail.com>
> Is timing out reply required methods the dbus daemon responsibility? Is it the
> responsibility? The mesh daemon responsibility? Ideally, the App just responds, but
we have no control over
> how Apps respond to method calls.
Timeouts do not exist at the protocol level, their implementation is purely a higher
dbus-daemon can be configured to limit the maximum time an application can take to
respond, but the default reply_timeout is set to -1 (infinite).
ell does not enable or enforce any timeouts for dbus method calls. Starting a timer for
each dbus call is quite expensive, so for now we have left this up to the application to
I suspect this is what we need to do... we have perhaps just the one method that
absolutely requires this time-out, so I agree that pushing this into all “send-with-reply”
calls might be overkill.
It does, however, create the potential for at least a temporary resource leak. The hashmap
gets saved for as long as it takes... if we time out the on the responde, is there
anyway to tell ELL to cancel and cleanup the hashmap?