[0.21] pass #[pyclass] by mutable reference to async fn

[rigens]

I'm sorry, I'm new to pyo3. Can anyone help me how to pass #[pyclass] object to async function. With regular functions I usually use PyRefMut, but it doesn't work with async fn because of PyRefMut is not Send + 'static

#[pyclass]
pub struct MyClass {}

#[pyfunction]
async fn foo(c: PyRefMut<MyClass>)->PyResult<()>{
    Ok(())
}

[adamreichold]

Take both py: Python and c: Py<MyClass> as parameters and call

let c = c.borrow_mut(py);

directly, i.e. call Py::borrow_mut.

[rigens]

Unfortunately I have the same error:

#[pyclass]
pub struct MyClass {}

#[pyfunction]
async fn foo(py: Python<'_>, c: Py<MyClass>)->PyResult<()>{
    let c_ref = c.borrow_mut(py);
    Ok(())
}

error[E0277]: `*mut pyo3::Python<'static>` cannot be sent between threads safely
   --> src/lib.rs:73:1
    |
73  | #[pyfunction]
    | ^^^^^^^^^^^^^
    | |
    | `*mut pyo3::Python<'static>` cannot be sent between threads safely
    | within this `{async block@src/lib.rs:73:1: 73:14}`

[rigens]

@adamreichold , thanks,

with your help I found a working solution, but it doesn't seem very soundness to me

#[pyfunction]
async fn foo(c: Py<MyClass>)->PyResult<()>{
    Python::with_gil(|py|{
        let c_ref = c.try_borrow_mut(py)?;
        Ok(())
    })
}

[adamreichold]

Ok, you can work around this by calling Python::with_gil yourself

#[pyclass]
pub struct MyClass {}

#[pyfunction]
async fn foo(c: Py<MyClass>)->PyResult<()>{
  Python::with_gil(|py| {
    let c_ref = c.borrow_mut(py);
    Ok(())
  })
}

but I wonder if this is a bug (the direct async integration is still pretty rough in 0.21) as I think I remember that we do hold the GIL when polling the future (with an opt-in to have it released before being polled).

[adamreichold]

but it doesn't seem very soundness to me

It should certainly be sound, we aim to not provide any unsound safe API. But yes, it should not really be necessary IIRC.

[wyfo]

The error is caused by a documented restriction.
The solution is also documented: you have to call Python::with_gil yourself, and it will have a negligible cost.

[wyfo]

Indeed, I start thinking that for non #[allow_threads] function, we should be able to release the restriction, not only for the GIL token, but also for the bound arguments. The idea would be to capture the raw arguments (the *mut #pyo3_path::ffi::PyObject pointers, wrapping them to make them Send) and do the extraction inside the future, with Python::assume_gil_acquired.

I may open a pull request after #3610 to do that, before #3611.

EDIT: Actually, I'm not sure the future will still be Send if we do that... I need to try, and maybe, we will discuss about a unsafe but sound workaround by implementing Send ourself.

[davidhewitt]

The future can probably store Py<T> smart pointers which are Send and convert to Bound<T> at zero cost. All that would be needed is to have some trait wizardry to convert the types into Py<T> as an intermediate state.

[wyfo]

Ok, forget it. The future will not be Send, because you can't hold !Send values across .await points 🤦‍♂️ That's why this restriction exists, and cannot be dropped. I'm not even sure that Ungil auto trait will help, because Python should stay !Send.
We managed to hack the restriction for the receiver because &self is Send.

[wyfo]

@davidhewitt we will have the issue of holding !Send values across .await points.

[davidhewitt]

Ah good point 👍