Is there any method to get GIL in async?

[Easonzero]

Is there any method to get GIL in async? It is useful when users call python from rust

async fn run_python() {
    let gil = Python::acquire_gil().await;
    let py = gil.python();
    do_something();
}
#[async_std::main]
async fn main() {
    run_python().await;
}

[davidhewitt]

I'm afraid Python::with_gil is the best choice at the moment. Because the GIL is like a sync Mutex, I'm not aware there's anything we can do in PyO3 to avoid a blocking wait at the moment.

[Easonzero]

@davidhewitt Maybe it is feasible to do so, although many specific details are not considered.
https://gist.github.com/rust-play/2168724b061bf6b8aa2f2d3c64bb235b

[davidhewitt]

I would strongly advise not using that. In particular:

async fn acquire_gil(&self) -> AsyncGILGuard<'_> {
    let _guard = self.inner.lock().await;
    let gil = Python::acquire_gil();
    AsyncGILGuard { _guard, gil }
}

This causes two waits: an async wait to acquire the Mutex, and then a blocking wait for Python::acquire_gil. Acquiring the Mutex won't guarantee that the GIL is ready to be acquired; this could even potentially deadlock your program.

If you really want a true async acquire_gil then I believe this would need upstream support in CPython. The only APIs we have accessible to us at the moment block the thread waiting for the GIL.

[Easonzero]

What I want to express is actually: blocking APIs will not block when they meet certain conditions. Therefore, as long as the asynchronous primitives are used to ensure that the blocking APIs will not be blocked when accessed, the blocking APIs can be converted to asynchronous APIs.

My example is written under your premise " the GIL is like a sync Mutex", that is, through asynchronous Mutex, it is guaranteed that there is only one coroutine that calls Python::acquire_gil() at the same time, so theoretically the call will not block if it is similar to a sync mutex. If this premise is not precise, such as GIL is actually more similar to a reentrant mutex, then this example is of course unreasonable, but it should not affect its feasibility (Asynchronous GIL can be implemented without additional support from CPython).

My English is not very good. These sentences are largely translated by Google. If there is any offense in the words, please understand, it is not my intention.

[mejrs]

Perhaps in this case you are better off having only one thread that acquires the gil and use channels to communicate between threads, if your program is multithreaded. Generally it is recommended that things like resources work better with message passing than passing around a mutex containing one.

[Easonzero]

@mejrs So at least we have reached a consensus: it is feasible to obtain GIL asynchronously. Why not try to support it in pyo3?
I'm the core maintainer of MegFlow, which uses Rust's asynchronous scheduler to schedule Python/Rust programs at the same time. It would be very helpful if pyo3 supports asynchronous acquisition of GIL, and I also think that this will be a very cool feature.

[davidhewitt]

it is guaranteed that there is only one coroutine that calls Python::acquire_gil() at the same time

@Easonzero I understand your point however I must disagree still with the implementation. Any number of other threads spawned from Python by threading.Thread, or even Rust threads which are not running async code, may also be waiting on acquire_gil. So I expect it to be very likely that calls to acquire_gil will block even with the companion async Mutex.

For this reason I think offering this API in PyO3 at the moment is misleading to users - if I use an async function from a library I expect it to be guaranteed that the function will never block.

In your own code you are able to control what other threads may be spawned, so I'm fine for you to do this in your own code if you choose.

It would be very helpful if pyo3 supports asynchronous acquisition of GIL, and I also think that this will be a very cool feature.

Please do understand that I very much want to have async support in PyO3 too. More research into how to best integrate async Rust and Python needs to be done before I think we are ready to provide anything in PyO3. A lot of progress has been made at https://github.com/awestlake87/pyo3-asyncio, however that implementation is very coupled to the Rust runtimes and I hope that anything in PyO3 core would be runtime-agnostic.

I still believe that an async acquire_gil is dependent on having upstream CPython support.

[mejrs]

So at least we have reached a consensus: it is feasible to obtain GIL asynchronously.

That's not what I said.