Calling blocking::Conenction::process() and also calling method calls will drop replies

[NZSmartie]

I'm having a hard time trying to wrap my head around this situation.

I've created a blocking::SyncConnection::new_system() that is used for querying a service. I would also like to listen for signals at the same time.
Initially I tried

// Set up some stuff
let my_connection = Arc::new(blocking::yncConnection::new_system()?);

// Spawn a new thread to process received signals
let connection = my_connection.clone();
thread::spawn(move || {
    loop { connection.process(Duration::from_secs(1)).unwrap(); }
});

// (Some time passes)

use dbus::blocking::stdintf::org_freedesktop_dbus::ObjectManagerInterfacesAdded as IA;
let token = my_connection.add_match(MatchRule::new(), |args: IA, _c, _msg| {
    debug!("Received 'InterfacesAdded' signal!");
    // impl: process the args here
    return true;
})?;

let proxy = my_connection.with_proxy("some.dest", "/some/path", Duration::from_secs(5));
// A race condition here may result in a `Err(Error("org.freedesktop.DBus.Error.NoReply", "Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken."))`.
let reply = proxy.call_method()?;

// Eventually after some more time
my_connection.remove_match(token)?;

Part of the problem, is that, as the thread loops, it will process messages as soon as they come in. But proxy.call_method()?; may have it's reply consumed by the process function since it does not know that call_method helper is waiting for a reply.

Also, the add_match will also wait for a reply that also gets consumed by the thread calling process on the connection, so that too my raise an Err...

It seems wrong that a work around is to add a mutex, that whenever a method is called on a connection, the thread may need check the mutex, and wait before calling process just to prevent replies from being dropped...

[NZSmartie]

Edit: Sorry, hit shift + enter too early and didn't finish writing my message

[diwic]

my_connection.add_match(MatchRule::new()

This matches all messages, including incoming method replies. You need a match rule that matches the right signal only:

SignalArgs::<ObjectManagerInterfacesAdded>::match_rule()

[diwic]

Actually, while the comment above is correct, that won't resolve the issue. I'd say this is a fundamental limitation of the blocking Connection. You're trying to use the blocking connection in a parallel/non-blocking way.

Would it be possible for you to switch to the nonblock/Tokio module instead? Or optionally have two blocking Connections?

[NZSmartie]

Thanks @diwic, I've opted to have a second blocking Connection behind a reentrant-mutex, so that when a add_match happens, the process loop is blocked until a response is received by the add_match then frees the connection to continue processing.

As for async, they can't be used yet, as I'm retrofitting an existing library to use DBus over a very deprecated set of operations.