Add support for sd_bus_set_method_call_timeout()

[meehand]

As it stands, there is no support in the library for adjusting the timeout away from the default. If support for sd_bus_set_method_call_timeout() was added, we could adjust the timeout.

[igo95862]

Hello @meehand

Sounds pretty straight forward to add.

However, is there a particular reason you want to tweak timeout?

[meehand]

Without going into too much detail I have a dbus command interface that allows me to run a hardware feature for an arbitrary amount of time. Once it completes it responds. As it stands I can only run that HW feature for a max of 25s before I no longer receive the response.

Another option is to open up access to the timeout argument that's ultimately sent to sd_bus_call.

[igo95862]

I see.

A bit strange implementation. I would have used signals. For example, Freedestkop Notifications returns a unique id when notification is created that can be later used to monitor signals when notification gets closed or invokes action.

Another option is to open up access to the timeout argument that's ultimately sent to sd_bus_call.

Hmm. Not sure how to implement this in current ORM. Maybe with a with block?

with dbus_timeout(60):
    await long_method()

[meehand]

It originally was designed to only be run for a small amount of time, but we're taking it outside of that original design.

I was was messing around with a fork and had it working with timeout as an additional member of DbusMethodCommon then just flowing down to the ultimate sd_bus_call. I'm sure you may object to that design though. I'm not opposed to the with block

[igo95862]

Hmm... Reading the man page aparently there is SYSTEMD_BUS_TIMEOUT environment variable to control the timeout.

https://man.archlinux.org/man/sd_bus_set_method_call_timeout.3.en#DESCRIPTION

[meehand]

Yeah, it's cached though, so no changing it at runtime.

[igo95862]

@meehand I added the SdBus.method_call_timeout_usec property in e7f3bb1. Can you give it a test? (remember that it is in microseconds)

As for controlling the timeout per call I would look in to that more in the future.

[meehand]

Trying it out now

[meehand]

This worked great!

[igo95862]

I just realized that it is possible to have extra methods for D-Bus method descriptor objects. So there can be an extra method to do a call with extra timeout. For example, calling some long_method with 60 second timeout and some_argument:

await  dbus_object.long_method.with_timeout(60)(some_argument)

I think the typing should work out.

[colazzo]

My original example of a timeout of 100 ms was perhaps too extreme I must say :-)
If we manage to have min. timeout of 1 second and precision of around 0.5 seconds is also fine.

More important is being able to have the longer timeouts than the default one of 25 seconds.
Ideally being able to set per method.

[igo95862]

The longer timeout should already be allowed by setting bus.method_call_timeout_usec to a large value. It is just the shorter timeout might not fire on time because the timeouts are only processed when there is data to read from D-Bus connection.

[colazzo]

Hi @igo95862 I think the timeout setting is not documented yet? Could you update the doc with this feature... also explain on which side you can apply the timeout (client side, or server side...).

[igo95862]

It is undocumented for now as all low-level API because it is not finalized yet.

[igo95862]

The high level interface

await  dbus_object.long_method.with_timeout(60)(some_argument)

can definitely work but the Jedi code auto completion does not support the ParamSpec yet. Without it there won't be function arguments help anywhere. Right now the async dbus method masquerade as an async functions.