Re: sd-bus delayed reply

[Lennart Poettering <lennart@xxxxxxxxxxxxxx>]

On Do, 31.01.19 19:58, Giacinto Cifelli (gciofono@xxxxxxxxx) 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)

Lennart

--
Lennart Poettering, Red Hat
_______________________________________________
systemd-devel mailing list
systemd-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/systemd-devel