[systemd-devel] sd_bus_get_unique_name returns -EBADMSG or -EBUSY

[Lennart Poettering]

On Mi, 07.04.21 12:17, Carlo Wood (carlo at alinoe.com) wrote:

> On Tue, 6 Apr 2021 18:41:21 +0200
> Lennart Poettering <lennart at poettering.net> wrote:
>
> > EBADMSG usually means that somehow an invalid dbus packet we couldn't
> > parse entered the stream. maybe some memory corruption thing? or maybe
> > you are using this in a threaded env without locking?
> >
> > Lennart
>
> Yes, that is the case. I was reading up on the demands,
> which I found on
> https://www.spinics.net/lists/systemd-devel/msg01779.html
>
> making me wonder why I went through the trouble of supporting
> dbus with my library :p (which aims at massive parallel
> execution without EVER blocking or going to sleep).

sd-bus is fully async. It only blocks if you call the functions that
are synchronous wrappers around async functions. e.g. sd_bus_call() is
actually more or less a synchronous wrapper around the same stuff that
sd_bus_call_async() does async.

Async means here the work is enqueued into the socket or client side,
and then dispatched by an event loop of sorts. The event loop can be
sd-event, or you can use any other you like, that has a poll()-like
glue interface.

You are supposed to have one sd-bus connection per thread though. It's
the model this is all built for. If you want to share one connection
among multiple threads, you need to do your locking around that
yourself.

> Libraries that do not support threading are a pain :/.

Well, depends what you mean by "supporting". sd-bus is written with
threads in mind, i.e. everything is broken down to local contexts,
there's no global non-fixed data and such. It's just a different model
that you might be used to: i.e. one connection per thread and locking
if desired must be done in your own code.

> It would really help if you could tell me a more fine-
> grained multi-threading demands; like - per connection.

D-Bus as a protocol is big on global ordering. It's thus not really
compatible with being dispatched in thread pools, because those would
basically randomize dispatch ordering.

It's a design decision of D-Bus.

> Surely I can execute sd_bus_* functions that deal with
> a different dbus* in parallel?

Yes. You are not supposed to share individual sd_bus objects (and
their associated helper objects) between multiple threads, unless you
do your own locking around it. But you can have as many sd_bus objects
you want and run the independently from any number of threads you
like, fully in parallel.

> As you stated in the linked email, there is no global state.
> So, I suppose that if I call any sd_bus_* function that
> all that I have to take into account is that the data
> that is passed to those functions is protected. If they
> use different connections, then no data should be shared,
> no?

Not sure I grok the question.

Lennart

--
Lennart Poettering, Berlin