On Mon, Mar 20, 2017 at 7:40 PM Stanislav Angelovič <angelovi...@gmail.com> wrote:
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. Yes, sd-bus was designed with asynchronous programming in mind. It prefers the sd-event event loop, but you can also integrate it into another event loop. The blocking calls all loop internally. Your programming language and/or framework might have a preferred DBus implementation already. For example, if you have a GLib/GTK event loop, I would recommend using GIO (GDBus) instead of sd-bus. Similarly, Qt has QDBus.
_______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel