[systemd-devel] sd-bus delayed reply

[Giacinto Cifelli]

Hi Lennart,
On Mon, Feb 4, 2019 at 1:15 PM Lennart Poettering
<lennart at poettering.net> wrote:
>
> On Do, 31.01.19 19:58, Giacinto Cifelli (gciofono at gmail.com) wrote:
>
> > > Depends on what you return in the handler function:
> > >
> > > 1. Returning < 0 means sd-bus will generate an automatic error reply
> > >    for you, taking the returned value as negative errno (or looking
> > >    into the sd_bus_error struct passed to you, which takes
> > >    precedence).
> > >
> > > 2. Returning 0 means it will generate an automatic response suggesting
> > >    that the method call was not handled.
> > >
> > > 3. Returning > 0 means however that you handled the message, and
> > >    sd-bus will not generate any reply.
> >
> > I am using the same technique and works fine for methods, but I have
> > problems with the properties:
> >    SD_BUS_WRITABLE_PROPERTY(property, signature, get_property,
> > set_property, 0, SD_BUS_VTABLE_UNPRIVILEGED)
>
> Properties are supposed to be cheap and quick. sd-bus doesn't support
> them to be async.
>
> Note that with properties your handlers do not process individual
> messages, but instead properties are usually requested in bulk (for
> example via the GetAllProperties() bus call, or even sent out
> graciously via PropertiesChanged(). This means that your handlers are
> just one supplier of data among many that are then combined into one
> message, and hence can't really delay processing or even take over
> processing on their own.
>
> In addition, property read requests are not supposed to fail,
> i.e. they should not result in complex operations but just simple data
> checks.
>
> All of this is baked into various bindings, for example GDBus
> aggressively caches properties and knows no concept whatsoever to
> report errors on property reads.
>
> Or in other words: if you have some piece of data that is expensive to
> get, that needs time, that might fail, then you should add an explicit
> GetXYZ() method for it, and properties are not the right concept.
>
> It's a pity this is nowhere documented more explicitly. We should work
> on that.
>
> (To clarify: this is not an sd-bus specific limitation, but pretty
> much a general D-Bus fact)

thank you for your insight, however I am faced with an existing dbus
API, for ofono.
I have to say that the API does use GetProperies/SetProperty, and
signals for PropertyChanged,  and not the properties above, but I
think it is really a design issue:
to power on a module (that can take several seconds) there should be a
SetPower(true) method, and not a SetProperty(Powered, true).

The point is, if I change the API, the clients will not be compatible
anymore, so it is not going to fly...

Anyway, thanks again.

>
> Lennart
>
> --
> Lennart Poettering, Red Hat

Giacinto