Add support for sd_bus_set_method_call_timeout() #53

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.

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()

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

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

Trying it out now

This worked great!

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.

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.

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...).

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

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.