> > > > please see the referenced + updated example project:
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@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/systemd-devel
