On Fr, 21.12.18 07:28, Jan Mueller (janmueller.email@xxxxxxxxxxxxxx) 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 _______________________________________________ systemd-devel mailing list systemd-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/systemd-devel