> > I have the following issue: > > An application does not receive dbus signals on its dbus file descriptor *while waiting* for a
> > dbus-method response. Considered time frame: between sending the method-call and receiving > > its response. After the response is being received, the (indefinitely) queued signal is not delivered > > until another signal / method call triggers the sdbus file descriptor (which is supervised by > > select()/epoll()). > Don't use select() anymore. It's inefficient and can't handle fds > > > 1024. Use poll() or epoll(). (I'll prep a patch now that removes any > > mention of select() from our man pages, as we shouldn't mislead users > > to ever use it.) > > Morever, when waiting on a bus object you need to use the fd returned > > by sd_bus_get_fd() and wait for the events returned by > sd_bus_get_events() (which are POLLIN/POLLOUT/… events). Yes this > > could benefit from documentation. The timeout passed to poll() should > > be the one returned by sd_bus_get_timeout() or shorter. > > Whenever poll() reports anything call sd_bus_process(), which will do > > the work. > > Lennart > Hey Lennart - thank you for the quick response! Ok, originally I stripped it down to select() for better comprehension. Swichting back to epoll + making use of sd_bus_get_events() did not help receiving the signals in this very situation. The basic communication between sender and receiver works fine so far though. I did already make use of sd_bus_get_fd() and sd_bus_process() - please see the referenced + updated example project: https://github.com/mue-jan/dbus-missing-signals-or-fd-issue By the way: sd_bus_get_events() returns "0" in the referenced code-example. The function-result printing is located right before the while(1) loop around epoll. Jan
_______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
