> > > > 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. > The link above still cotnains references to select()... You're right, there's still a reference to select() within the receiver which is not the software under test - but the sender is. > ... 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()? I would have expected the poll/epoll loop to collect the incoming sdbus-fd anyways and to schedule the event right after the blocking sd_bus_call()-call. Is the only way to keep synchronization + process every signal in any situation, to call sd_bus_process() manually right after leaving a sd_bus_call()-call?
_______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
