Cython 结构成员范围

Question

我在 Cython 中有一个使用 char * 成员的数据结构。

发生的情况是成员值似乎失去了在为成员分配值的函数之外的范围。请参阅此示例（使用 IPython）：

[nav] In [26]: %%cython -f 
      ...: ctypedef struct A: 
      ...:     char *s 
      ...:      
      ...: cdef char *_s 
      ...:      
      ...: cdef void fn(A *a, msg): 
      ...:     s = msg.encode() 
      ...:     a[0].s = s 
      ...:  
      ...: cdef A _a 
      ...: _a.s = _s 
      ...: fn(&_a, 'hello') 
      ...: print(_a.s)          
      ...: print(b'hola') 
      ...: print(_a.s)          
b'hello'
b'hola'
b"b'hola'"

看起来_a.s 在fn 之外被释放，并且被分配了内存中适合该插槽的任何垃圾。

这仅在特定情况下发生。例如，如果我将 b'hello' 分配给 s 而不是 fn() 内的编码字符串，则正确的字符串将在函数外部打印。

如您所见，我还为 char 变量添加了一个额外的声明，并在执行 fn 之前将其分配给 struct，以确保 _a.s 指针不会超出范围。但是，我怀疑问题是将成员分配给函数范围内的变量。

这里到底发生了什么，我该如何解决这个问题？

谢谢。

Answer 1

您的问题是，指针 a.s 在创建后立即在 fn 函数中悬空。

当调用msg.encode() 时，会创建临时字节对象s，并将其缓冲区的地址保存到a.s。然而，紧接着（即在函数退出时）临时字节对象被破坏并且指针变得悬空。

因为字节对象很小，Python's memory manager 在竞技场中管理它的内存——这保证了当你访问地址时没有段错误（你很幸运）。

虽然临时对象被销毁，但内存并没有被覆盖/清理，因此从A.s 的角度来看，临时对象看起来好像还活着。

每当您创建一个与临时对象大小相似的新字节对象时，竞技场中的旧内存可能会被重用，因此您的指针a.s 可以指向新分配的字节对象的缓冲区。

顺便说一句，你会直接使用a[0].s = msg.encode()（我猜你这样做了），Cython 不会构建并告诉你，你试图说对临时 Python 对象的引用。添加显式引用欺骗了 Cython，但对您的情况没有帮助。

那该怎么办呢？哪种解决方案合适取决于大局，但可用的策略是：

1. 管理A.s的内存。 IE。手动保留内存，从临时对象中复制，完成后立即释放内存。
2. 管理引用计数：将PyObject * 添加到A-struct。将临时对象分配给它（不要忘记手动增加引用计数器），完成后立即减少引用计数器。
3. 将临时对象的引用收集到一个池中（例如列表），这将使它们保持活动状态。不需要对象时立即清除池。

并不总是最好的，但最简单的是选项 3 - 您不必管理内存而不是引用计数：

%%cython
...
pool=[]   
cdef void fn(A *a, msg):    
    s = msg.encode()
    pool.append(s) 
    a[0].s = s

---

虽然这并不能解决主要问题，但在这种情况下，使用 PyUnicode_AsUTF8（启发 by this answer）可能是一个令人满意的解决方案：

%%cython

# it is not wrapped by `cpython.pxd`:
cdef extern from "Python.h":
    const char* PyUnicode_AsUTF8(object unicode)
...

cdef void fn(A *a, msg): 
 a[0].s = PyUnicode_AsUTF8(msg) # msg.encode() uses utf-8 as default.

这至少有两个优点：

• 只要msg 还活着，指针a[0].s 就有效
• 调用PyUnicode_AsUTF8(msg)比msg.encode()快，因为它重用了缓存的缓冲区，所以第一次调用后基本上O(1)，而msg.encode()至少需要复制内存并且是O(n)和n-字符数。