[systemd-devel] sd-bus connections & authentication timeout

Lennart Poettering lennart at poettering.net
Thu Mar 30 14:00:11 UTC 2017


On Mon, 20.03.17 19:40, Stanislav Angelovič (angelovic.s at 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


More information about the systemd-devel mailing list