On Mo, 17.12.18 11:28, Jan Mueller (janmueller.email@xxxxxxxxxxxxxx) wrote: 65;5402;1c > > > please see the referenced + updated example project: > > > https://github.com/mue-jan/dbus-missing-signals-or-fd-issue > > > You need to call the three calls on *every* loop iteration, and update fd/ > > events/timeout on the epoll object before you can go to sleep. The I/O > events, > > timeouts, fd can change on each iteration, hence this requirement. > (Instead of > > epoll consider just using ppoll()/poll() where this is easier.) > > Hey Lennart, sorry for the delayed response. > I reworked the above mentioned example once again, (re-) configuring the > poll- > filedescriptors on each loop-iteration right before the poll()-call. > The behavior is still the same. > As long as the sender is blocked within its own sd_bus_call() (waiting for > the > reply-message), sent signals won't trigger its sd_bus-filedescriptor. The link above still cotnains references to select()... I am not sure I grok what are you trying to do, but note that if you do sd_bus_call(), then that's a synchronous method call, and thus any client calling that will not process any events until the reply msg is received. This call is convenient, but probably only a good idea to use in client that is rather simple and doesn't need to react to other events while waiting for the reply. In more complex programs, and in particular programs that offer bus methods to other peers on their own it's generally not wise to use this API but instead use sd_bus_call_async() which will enqueue the method call, then allow you to process any other message you'd like and eventually dispatch the reply to the specified callback function. But then again, I am not grokking what you are trying to do. Lennart -- Lennart Poettering, Red Hat _______________________________________________ systemd-devel mailing list systemd-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/systemd-devel