On Mon, 20.03.17 19:40, 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? sd-bus is not thread-safe, you'd need to lock around this yourself. It is written in a threads-aware style however, which permits you doing it and it keeps very little static state, and the one it keeps is either managed per-thread implicitly or protected by mutexes. My recommendation would be to either run a proper event loop in your threads (for example sd-event, or whatever you like), or only keep the connection around for as long as you need, and close it right-away. Async programming (i.e. going for a proper event loop) of course gets you the best performance. Lennart -- Lennart Poettering, Red Hat _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel