Question

我在列表中有一个multiprocessing.Process对象的集合，它们都使用我称之为“进程安全队列”的相同实例，以便在进程安全中进行通信（线程安全但具有进程）到父进程的方式，它负责管理线程。

当子进程将某些内容放入队列时，它会调用ProcessSafeQueue（）。enqueue（），它首先获取多处理。管理器＆gt; RLock，然后写入队列，最后释放锁。

在这种情况下，它是子进程的pid。这是错误的追溯。

Traceback (most recent call last): 
File /usr/lib/python2.5/site-packages/my_project/some_module.py, line 87, in send_data
    q.enqueue(os.getpid())
File /usr/lib/python2.5/site-packages/my_project/some_module.py, line 33, in enqueue
    self.lock.acquire()
File /usr/lib/python2.5/site-packages/processing/managers.py, line 979, in acquire
    return self._callMethod(\'acquire\', (blocking,))
File /usr/lib/python2.5/site-packages/processing/managers.py, line 740, in _callMethod
    self._connect()
File /usr/lib/python2.5/site-packages/processing/managers.py, line 727, in _connect
    connection = Client(self._token.address, authkey=self._authkey)
File /usr/lib/python2.5/site-packages/processing/connection.py, line 187, in Client
    answerChallenge(c, authkey)
File /usr/lib/python2.5/site-packages/processing/connection.py, line 425, in answerChallenge
    message = connection.recvBytes()

这是实际的错误：

IOError：[Errno 11]资源暂时不可用

我想知道是否有人可以帮助我理解为什么在应用程序成功运行约7个小时后我可能会收到此错误。

Answer 1

我遇到了类似的问题，我通过删除socket.setdefaulttimeout解决了这个问题。

Answer 2

这里的答案是错误完全是误导。 Resource temporarily unavailable实际上意味着在读取套接字时发生了一些错误。这可能是一个auth错误，或者根本没有可读的数据（虽然我不确定为什么会产生错误......实际上它确实存在）。这里的解决方案是抑制错误并重试。

[在使用Python进行并发的几年经验后更新]

我发现设计我的并发模型以减少/删除 - 完全需要同步机制（锁，队列或信号量）既简化了我的设计，又使其工作时不那么脆弱，没有我上面描述的错误。

<多处理>经理（）＆gt; RLock错误：

2 个答案: