我有一个自定义模拟器(用于生物学)在 64 位 Linux(内核)上运行 版本 2.6.28.4) 使用 64 位 Python 3.3.0 CPython 解释器的机器。

因为模拟器依赖于许多独立的实验来获得有效的结果， 我内置了用于运行实验的并行处理。之间的通信 线程主要出现在具有托管的生产者-消费者模式下 多处理队列 (doc)。 架构概要如下:

• 一个处理生成和管理进程和各种队列的主进程
• N 个进行模拟的工作进程
• 1 个结果消费者进程，它使用模拟结果并对结果进行排序和分析

主进程和工作进程通过输入 Queue 进行通信。 同样，工作进程将它们的结果放在输出 Queue 中 结果消费者进程从中消费项目。最终结果消费者 对象通过多处理管道传递 ( doc ) 回到主进程。

一切正常，直到它尝试将 ResultConsumer 对象传递回 通过 Pipe 的主进程:

Traceback (most recent call last):
  File "/home/cmccorma/.local/lib/python3.3/multiprocessing/process.py", line 258, in _bootstrap
    self.run()
  File "/home/cmccorma/.local/lib/python3.3/multiprocessing/process.py", line 95, in run
    self._target(*self._args, **self._kwargs)
  File "DomainArchitectureGenerator.py", line 93, in ResultsConsumerHandler
    pipeConn.send(resCon)
  File "/home/cmccorma/.local/lib/python3.3/multiprocessing/connection.py", line 207, in send
    self._send_bytes(buf.getbuffer())
  File "/home/cmccorma/.local/lib/python3.3/multiprocessing/connection.py", line 394, in _send_bytes
    self._send(struct.pack("!i", n))
struct.error: 'i' format requires -2147483648 <= number <= 2147483647

我理解前两条轨迹(Process 库中未处理的退出)， 第三个是我的代码行，用于将 ResultConsumer 对象发送到 管道到主进程。最后两条痕迹是它得到的地方 有趣的。 Pipe 挑选发送给它的任何对象并传递 结果字节到另一端(匹配连接)，在那里它被取消 在运行 recv() 时。 self._send_bytes(buf.getbuffer()) 正在尝试 发送腌制对象的字节。 self._send(struct.pack("!i", n)) 是 试图用长度为 n 的整数(网络/大端)打包结构， 其中 n 是作为参数传入的缓冲区的长度(struct 库处理 Python 值和 C 结构之间的转换，表示为 Python 字符串，参见 the doc ).

此错误仅在尝试大量实验时发生，例如10个实验 不会导致它，但 1000 会一致(所有其他参数保持不变)。我最好的 关于为什么抛出 struct.error 的假设是字节数 试图被推下管道超过 2^32-1 (2147483647)，或 ~2 GB。

所以我的问题有两个方面:

1. 我的调查陷入困境，因为 struct.py 本质上只是 从 _struct 导入，我不知道它在哪里。

2. 考虑到底层架构，字节限制似乎是任意的 64 位。那么，为什么我不能传递比这更大的东西呢？另外，如果我 无法更改此问题，是否有针对此问题的任何好的(阅读:简单的)解决方法？

注意:我不认为使用 Queue 代替 Pipe 可以解决问题， 因为我怀疑 Queue 使用了类似的 pickling 中间步骤。 编辑:正如 abarnert 的回答中所指出的，这条注释是完全不正确的。

最佳答案

I'm getting stuck with my investigations as struct.py essentially just imports from _struct and I have no idea where that is.

在 CPython 中，_struct是从 _struct.c 构建的 C 扩展模块在Modules源树中的目录。您可以在线找到代码here .

每当foo.py做 import _foo ，那几乎总是一个 C 扩展模块，通常是从 _foo.c 构建的.如果找不到 foo.py根本上，它可能是一个 C 扩展模块，由 _foomodule.c 构建.

通常也值得一看 equivalent PyPy source ，即使您没有使用 PyPy。他们用纯 Python 重新实现了几乎所有扩展模块——对于其余部分(包括本例)，底层的“扩展语言”是 RPython，而不是 C。

但是，在这种情况下，您不需要知道 struct 是如何实现的。正在超出文档中的范围。

The byte limit seems arbitrary given that the underlying architecture is all 64-bit.

查看它调用的代码:

self._send(struct.pack("!i", n))

如果你看the documentation , 'i'格式字符明确表示“4 字节 C 整数”，而不是“ssize_t 是什么”。为此，您必须使用 'n' .或者你可能想显式地使用 long long，带 'q' .

你可以 monkeypatch multiprocessing使用 struct.pack('!q', n) .或者 '!q' .或者以 struct 以外的方式对长度进行编码.当然，这会破坏与未打补丁的兼容性 multiprocessing ，如果您尝试在多台计算机或其他设备上进行分布式处理，这可能是个问题。但这应该非常简单:

def _send_bytes(self, buf):
    # For wire compatibility with 3.2 and lower
    n = len(buf)
    self._send(struct.pack("!q", n)) # was !i
    # The condition is necessary to avoid "broken pipe" errors
    # when sending a 0-length buffer if the other end closed the pipe.
    if n > 0:
        self._send(buf)

def _recv_bytes(self, maxsize=None):
    buf = self._recv(8) # was 4
    size, = struct.unpack("!q", buf.getvalue()) # was !i
    if maxsize is not None and size > maxsize:
        return None
    return self._recv(size)

当然，不能保证这种变化就足够了；您将需要通读其余的周围代码并对其进行测试。

Note: I suspect that using a Queue in place of a Pipe will not solve the issue, as I suspect that Queue's use a similar pickling intermediate step.

好吧，这个问题与酸洗无关。 Pipe没有使用 pickle发送长度，它使用 struct .您可以验证 pickle不会有这个问题:pickle.loads(pickle.dumps(1<<100)) == 1<<100将返回 True .

(在早期版本中，pickle 也在处理大对象时存在问题——例如，一个 list 的 2G 元素——这可能会导致大约 8 倍于大对象的问题你目前正在击球。但这已被 3.3 修复。)

与此同时……试一试看看会不会更快，而不是深入研究源代码来弄清楚它是否可行？

另外，你确定你真的想通过隐式 pickling 传递一个 2GB 的数据结构吗？

如果我正在做一些缓慢且耗费内存的事情，我宁愿将其明确化——例如，pickle 到一个临时文件并发送路径或 fd。 (如果您使用的是 numpy 或 pandas 或其他东西，请使用其二进制文件格式而不是 pickle ，但想法相同。)

或者，更好的是，共享数据。是的，可变的共享状态不好……但是共享不可变对象很好。无论你有 2GB 的空间，你能把它放在 multiprocessing.Array 中吗？ , 或者把它放在 ctypes 中您可以通过 multiprocessing.sharedctypes 共享的数组或结构(属于……的数组或结构) , 或 ctypes它来自 file那你mmap双方，还是……？有一些额外的代码来定义和分离结构，但当 yield 可能如此之大时，值得尝试。

最后，当您认为您在 Python 中发现了错误/明显缺失的功能/不合理的限制时，值得查看错误跟踪器。看起来像 issue 17560: problem using multiprocessing with really big objects?正是您的问题，并且有很多信息，包括建议的解决方法。

关于python - 使用管道在进程之间传输 Python 对象时的字节限制？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/16576386/