[systemd-devel] Fwd: sdbus-filedescriptor does reproducibly NOT get triggered in a specific situation

[Lennart Poettering]

On Fr, 21.12.18 07:28, Jan Mueller (janmueller.email at googlemail.com) wrote:

> > > > > please see the referenced + updated example project:
> > > > > https://github.com/mue-jan/dbus-missing-signals-or-fd-issue
>
> Hey Lennart, again sorry for the delayed response.
>
> I tried to illustrate the signal-issue for you, please check the github-
> repository once again.

sd_bus' will set nonblocking mode (O_NONBLOCK) on the fds it deals
with, no need to ever touch that. it doesn't support blocking fds.

sd_bus_get_events() returns the mask to pass to poll(), do not OR in
POLLIN there.

You need to call sd_bus_process() after *every* poll() invocation, not
only when POLLIN was seen on the sd-bus fd. Right now your code
conditions that out afaics on POLLIN on the sd-bus fd.

> > ... will not process any events until the reply msg is received.
> I don't fully get this sentence this cutout belongs to, but I'm aware, that
> the function blocks until timeout/reception of the reply-message. Does this
> imply, that incoming fd-events (or only sd_bus-events?) are ignored and not
> forwarded to poll()?

which poll event happens on the connection fd, or whether there's any
at all should not be your concern. The rule is: whenever you return
from poll() call sd_bus_process(), regardless what the reason was, if
it was POLLIN on the bus connection fd, if it was POLLOUT, if it was a
timeout or an event on a completely different fd.

You should configure poll() with the data you get from
sd_bus_get_fd() + sd_bus_get_events() + sd_bus_get_timeout(), but
that's all, do not use the data for anything else, and do not use it
for conditioning sd_bus_process() later on. sd_bus_process() will
figure out by itself whether there's new stuff to do or not.

Lennart

--
Lennart Poettering, Red Hat