Proxy with signal reception connected to session bus about sdbus-cpp HOT 7 CLOSED

Hi, whether you have session bus or system bus is irrelevant, the way of working with it is the same. How are you passing session bus object to the proxy? By moving it inside the proxy (the unique_ptr<IConnection>&& c-tor overload)? If so, the enterProcessingLoopAsync() shall get called automatically whenever the proxy listens to at least one signals, and there shall be no race condition situations. Signal handlers get invoked from that internal thread using a connection copy, whereas method and propety calls take place in the context of the client thread via the original connection.

from sdbus-cpp.

How are you passing session bus object to the proxy? By moving it inside the proxy?

Yes.
I now that enterProcessingLoopAsync() should be called automatically. But I still can't use signals in the same proxy that methods and properties.
BTW: So far for workaround this problem I use two separate Bus Connections: one for signals, second for methods and properties. Additionally I must call "manually" enterProcessingLoopAsync for connection to receive signals.

from sdbus-cpp.

I have an issue that I think is related to this as well. The tutorial states:

The object proxy can be created by either explicitly passing the connection object to it, or without the connection object. In the former case, we have the freedom of creating our own connection (to either system bus or to session bus) and then we can just move that connection object as the first argument of the proxy factory. The latter option is more convenient (no messing with connection for proxy), the proxy will create and manage its own connection, but the limitation is that it will be the connection to the system bus only.

Does this mean that the built-in support for listening to signals on a separate thread only works for the System bus?

from sdbus-cpp.

@zalesm Unless there is a specific trouble in your system (outside of sdbus-c++), then signal reception in your described case should work without you having to do anything else with the bus connection, be it system bus or session bus. This is verified behavior.

My guess here is that you're not std::move-ing the connection to the proxy object as you have stated. Because otherwise you could not work with the connection after proxy creation - it is emptied, because it is std::moved. I suppose you're just placing an lvalue-reference there. In this case, the hidden async processing does not take place, but sdbus-c++ relies on the fact that you manage the processing loop upon this connection, since you are still the owner of the connection.

And here is where I apologize for not being clear about this in the tutorial. I've fixed the tutorial in master branch - see section Proxy and D-Bus connection. Please let me know whether the information there make sense to you.

TLDR If your want automatic stuff, just std::move the session connection into the proxy constructor. Otherwise, you must handle the processing loop upon the connection if keep its ownership.

@rogerdahl No, the built-in support for listening to signals works for any bus (system, session). I've tried to clarify that, and there is a reworked section Proxy and D-Bus connection. Please let me know whether the information there make sense to you.

from sdbus-cpp.

@sangelovic Thank you, I think that clears it up nicely!

from sdbus-cpp.

Thanks. This explanation should help me solve the problem.

from sdbus-cpp.

@zalesm Great. If this helped to fix your problem, you may close the issue. Thanks.

from sdbus-cpp.