Hacktoberfest 2026:维护者为十月标记出来的 issue,仍然开放、适合新手。 浏览 Hacktoberfest issue

Is it sound to use a slice of numpy::PyReadonlyArray inside pyo3::allow_threads()?

未关闭
#497 1 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

还没有人认领这个 Issue。

评估

难度
4/5
预计耗时
3-5 天
新手友好度
25/100
Issue 类型
功能
描述清晰度
需要澄清
活跃度
停滞
技术栈
numpy, python, rust
领域
api, backend

调研方向

从 issue 中所示的 ema binding 和 core_ema 入口点开始,然后阅读 PyReadonlyArray 借用文档以及 pyo3::Python::allow_threads 的行为。完成的标准是形成有文档记录且得到项目支持的安全性结论,或形成范围明确的更改或 workaround,并由 maintainers 确定任何相关示例或测试。

由索引模型根据 Issue 内容生成。

描述

Greetings,

My goal is to implement an efficient (and safe) way to wrap a Rust function, using numpy::PyReadonlyArray, with zero-copy and GIL release during computation.

My question is general, but here is a concrete example from my EMA function binding:

use crate::indicators::ema::core_ema;
use numpy::{PyArray1, PyArrayMethods};
use pyo3::pyfunction;

#[pyfunction(signature = (data, window_size = 14, alpha = None))]
pub(crate) fn ema<'py>(
    py: pyo3::Python<'py>,
    data: numpy::PyReadonlyArray1<'py, f64>,
    window_size: usize,
    alpha: Option<f64>,
) -> pyo3::PyResult<pyo3::Py<numpy::PyArray1<f64>>> {
    let slice = data.as_slice()?;

    let py_array_out = PyArray1::<f64>::zeros(py, [len], false);
    let py_array_ptr = unsafe { py_array_out.as_slice_mut()? };

    py.allow_threads(|| core_ema(slice, window_size, alpha.into(), py_array_ptr))
        .map_err(|e| pyo3::exceptions::PyValueError::new_err(format!("{:?}", e)))?;

    Ok(py_array_out.into())
}

I want to release the GIL to enable multithreading. I wonder how to do it safely. Or if it's possible.

The documentation of numpy::PyReadonlyArray says:

An instance of this type ensures that there are no instances of PyReadwriteArray, i.e. that only shared references into the interior of the array can be created safely

Additionnally, in the numpy module borrow documentation, it says:

The aim of this module is to ensure that safe Rust code is unable to violate these requirements on its own. We cannot prevent unchecked code - this includes unsafe Rust, Python or other native code like C or Fortran - from violating them. Therefore the responsibility to avoid this lies with the author of that code instead of the compiler

So, in my understanding, I get a reference to input data which is owned by Python and can, in theory, be changed from the outside (e.g. by another Python thread). So in my understanding, the answer should be 'no' it is not sound. But I'm not sure if there is a way, or a workaround or a good practice or if I just need to avoid using allow_thread with PyReadonlyArray1.

Thanks a lot for your time.

主要语言
Rust
星标
1.4k
派生
141
平均合并
16 分钟
30 天内合并 PR
3

贡献指南

这个仓库没有索引到贡献指南

从这里开始

  1. 先读完整个 Issue,再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库,在一个分支上完成修改。
  4. 提交 Pull Request,并在描述里引用这个 Issue 编号。

PyO3/rust-numpy 的其他 Issue

查看 PyO3/rust-numpy 的全部 Issue

相似的 Issue

更多 Rust Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。