Hi Jan, thanks for quick response. Instead of sd_bus_process(), we could perhaps use sd_bus_flush() after creating the connection, as that one actually processes the requests until the connection changes state to 'running'. I tried this and it helped.
Regarding polling, I understand, but I fear this way we could get race condition on the connection instance, since we'd have a thread doing the polling and processing in a loop on the connection, and some other thread (say handling the UI, or an external system event, or incoming DBus call from another connection or whatever else) issuing a DBus call on the same connection. I think the connection instance is not thread-safe, as once I experienced such data race related problems. Maybe there is another way of doing that? One that comes to my mind is having just one single thread handling the connection and communication through it, but then it would have to poll on other fd's as well, to be able to communicate with other threads, for example to get DBus call request from the UI thread and perform it on the connection. This involves asynchronous programming paradigm for quite a simple thing, IMHO. What do you think? Thank you, Stanislav. On Mon, Mar 20, 2017 at 5:19 PM, Jan Alexander Steffens < jan.steff...@gmail.com> wrote: > On Mon, Mar 20, 2017, 17:14 Jan Alexander Steffens <jan.steff...@gmail.com> > wrote: > >> >> You could try calling sd_bus_process(bus, NULL) in a loop while it >> returns >0 so that the initial hello is handled. >> > > Actually, never mind, this is not reliable. IIRC the initial handshake has > multiple steps so this can return zero before everything is done. Can't get > around polling to do this properly. >
_______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel