Importing python module causes SIGINT to be ignored

Bug Description

Importing some python modules from rust causes a SIGINT signal to be ignored, even after python is no longer in scope.

(I'm not sure if the problem is PyO3, tokio, or if I haven't used the interface properly, so please let me know if this is the wrong place for this issue.)

Steps to Reproduce

cargo run can be interrupted with CTRL-C, but cargo run -F hang cannot.

---

main.rs

use std::time::Duration;

use pyo3::prelude::*;

#[tokio::main(flavor = "current_thread")]
async fn main() {
    #[cfg(feature = "hang")]
    run("foo");

    #[cfg(not(feature = "hang"))]
    run("bar");

    println!("Finished with pyo3");

    let handle = tokio::spawn(async {
        tokio::time::sleep(Duration::from_millis(10_000)).await
    });
    handle.await.unwrap();
}

pub fn run(name: &str) {
    let src_str = "
def foo():
    import matplotlib

def bar():
    import os
    ";
    Python::with_gil(|py| {
        let module: &PyModule = PyModule::from_code(py, src_str, "", "").unwrap();
        let _res = module.getattr(name).unwrap().call0();
    });
}

Cargo.toml

[package]
name = "pyo3_test"
version = "0.1.0"
edition = "2021"

[features]
hang = []

[dependencies]
tokio = { version = "1.20.1", features = ["macros", "rt", "time"] }
pyo3 = { version = "0.16.5", features = ["auto-initialize"]}

Backtrace

No response

Your operating system and version

Ubuntu 20.04.4 / Linux 5.4.0-124-generic

Your Python version (python --version)

Python 3.8.5

Your Rust version (rustc --version)

rustc 1.63.0 (4b91a6ea7 2022-08-08)

Your PyO3 version

0.16.5

How did you install python? Did you use a virtualenv?

miniconda
Occurs both with and without virualenv.

Additional Info

No response

Start by reproducing the two cases with cargo run and cargo run -F hang from the main.rs and Cargo.toml example, then inspect the run function around Python::with_gil and the listed Tokio and PyO3 versions. Done means determining why SIGINT remains ignored after the Python import and confirming that interruption works after the Python call as well as during the normal run.