<div dir="ltr"><div dir="ltr"><div>> > > > please see the referenced + updated example project:</div><div>> > > > <a href="https://github.com/mue-jan/dbus-missing-signals-or-fd-issue">https://github.com/mue-jan/dbus-missing-signals-or-fd-issue</a></div><div><br></div><div>Hey Lennart, again sorry for the delayed response.</div><div><br></div><div>I tried to illustrate the signal-issue for you, please check the github-</div><div>repository once again.</div><div><br></div><div>> The link above still cotnains references to select()...</div><div>You're right, there's still a reference to select() within the receiver which</div><div>is not the software under test - but the sender is.</div><div><br></div><div>> ... will not process any events until the reply msg is received.</div><div>I don't fully get this sentence this cutout belongs to, but I'm aware, that</div><div>the function blocks until timeout/reception of the reply-message. Does this</div><div>imply, that incoming fd-events (or only sd_bus-events?) are ignored and not </div><div>forwarded to poll()?</div><div>I would have expected the poll/epoll loop to collect the incoming sdbus-fd</div><div>anyways and to schedule the event right after the blocking sd_bus_call()-call.</div><div><br></div><div>Is the only way to keep synchronization + process every signal in any </div><div>situation, to call sd_bus_process() manually right after leaving a </div><div>sd_bus_call()-call?</div></div></div>