python - 天真地使用 Python 多处理会遇到什么问题？

Question

我们正在考虑重构具有复杂 GUI 的大型应用程序，该应用程序以与后端分离的方式隔离，以使用新的 (Python 2.6) 多处理模块。 GUI/后端界面使用带有双向交换消息对象的队列。

我刚刚得出的结论(暂定，但请随时确认)是“对象标识”不会在多处理接口(interface)中保留。当前，当我们的 GUI 向后端发布消息时，它期望返回相同的消息并将结果附加为属性。它使用对象标识(if received_msg is message_i_sent:)在某些情况下识别返回的消息……这似乎不适用于多处理。

这个问题是问你在实际使用中见过或者能想象到在天真地使用多处理模块时会遇到什么“陷阱”，尤其是在重构中现有的单进程应用程序。请说明您的回答是否基于实际经验。为问题提供可用的解决方法的奖励积分。

编辑:尽管我提出这个问题的目的是一般收集问题的描述，但我认为我犯了两个错误:我从一开始就将其设为社区维基 (这可能会让很多人忽略它，因为他们不会获得声望点数)，我提供了一个过于具体的例子——虽然我很欣赏答案——可能让很多人错过了一般回应的请求。我可能会在一个新问题中重新措辞并重新提出这个问题。现在我接受一个最好的答案只是为了关闭与我包含的具体示例有关的问题。感谢那些回答的人!

Answer 1

我本身并没有使用过多处理，但出现的问题与我在其他两个领域的经历类似:分布式系统和对象数据库。 Python 对象标识可以是福也是祸!

至于一般陷阱，如果您正在重构的应用程序可以确认任务是异步处理的，这会有所帮助。否则，您通常最终会管理锁，而您通过使用单独的进程可以获得的大部分性能将因等待这些锁而丢失。我还将建议您花时间构建一些用于跨进程调试的脚手架。真正的异步过程往往做的事情远远超过头脑所能承受和验证的——或者至少是我的头脑!

对于概述的具体情况，当项目排队和返回时，我会在流程边界管理对象标识。发送待处理的任务时，用id()注解任务，并以id()为键将任务实例存储在字典中。当任务更新/完成时，通过 id() 从字典中检索确切的任务，并将新更新的状态应用于它。现在将保留确切的任务及其身份。