[systemd-devel] Fwd: sdbus-filedescriptor does reproducibly NOT get triggered in a specific situation

[Lennart Poettering]

On Mo, 17.12.18 11:28, Jan Mueller (janmueller.email at googlemail.com) 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