Shared mutable object in crossroads property handler

[Taha-Firoz]

I need to have a shared mutable reference to the underlying object in the cross roads handler. In order to achieve that I've wrapped the object in an Arc<Mutex<...>> but when I want to access the object inside of a property handler I can't seem to get it working. I don't know if the Arc is exactly necessary.

I'm using tokio::sync::Mutex which requires an await to lock,

iface_builder.property("Device")
            .get(|prop, device:&mut Arc<Mutex<Manager>>| { 
                  ...  
                }
            );

This is fine but when I actually try to lock the mutex to use it I need to await it. So I saw a method called get_async but I keep getting this error when I try to do it

iface_builder.property("Device")
            .get_async(|prop, device:&mut Arc<Mutex<Manager>>| { 
                    async move{
                        let s = device.lock().await;
                        s.is_online
                    }
            );

I get this error

type mismatch resolving `<impl futures::Future as futures::Future>::Output == PhantomData<(_, ())>`
expected enum `Option<Vec<std::string::String>>`
 found struct `PhantomData<(_, ())>`

I don't really understand what to do here now :/ any help would be appreciated. I'm trying to wrap a DBus interface over a service that's running a separate tokio task which is why I think I need the Arc<Mutex<...>>

[surban]

You need to call PropContext::reply instead of returning the value directly, i.e. prop.reply(Ok(s.is_online)) in the last line of your async block.

[diwic]

Okay, so this is more of a "async closures in Rust" problem and less of a "dbus-crossroads" problem. But long story short, you probably want your device in an Arc and do something like:

.get_async(|mut prop, device|
    let d = device.clone();
    async move {
        let s = d.read().await;
        prop.reply(Ok(s.is_online))
    }
);

[diwic]

...and this is because device is only mutably borrowed until the first await point. It can only be that, because when awaiting, get_async can be called in parallel which means that the second call to get_async will also need its mutable borrow of device.

[Taha-Firoz]

Okay everything's compiling now!

[Taha-Firoz]

@diwic till when do you think you'll publish the crate with the fix? I really appreciate all the help though, thank you!

[diwic]

How about ... drum roll ... right now? Enjoy!