我有一个python框架，必须以插件的形式执行bash脚本。 我们使用多处理模块来创建工作进程，从多处理.JoinableQueue中选择插件细节，并使用subprocess.Popen（）执行插件。
据观察，shell脚本生成的最终输出被截断，最终导致整个执行浪费。
因此我们尝试转移到python线程，以便维护子进程机制的工作者生成shell脚本进程。截断不再发生了。但线程非常慢（由于GIL），对信号和事件的响应也是不确定的（可能是由于GIL发布时间）。
我已经阅读过许多地方，包括stackoverflow中的其他问题，多处理模块对stdout进行缓冲。我们知道这是问题所在。但无法找到合适的解决方案，因为我们无法从python中为sys.stdout.flush提供shell脚本必须回显到文件的数据。
我们还尝试了一些示例的os.fsync，并且没有发生截断。同样，它不能直接用于我们的目的，因为框架不知道shell脚本创建的文件的名称。框架只收回最终档案。
我的问题是，有没有办法阻止多处理模块产生的进程中的缓冲？请问python解释器的-u选项在这里有用吗？或者/usr/lib64/python2.6/multiprocessing中对python库的任何修改都会清除这个问题吗？
答案 0 :(得分：1)
我们发现脚本中通过ssh发送的命令是在输出中被截断的命令。
为此，我们使用了ssh的-n标志，解决了这个问题。没有更多的截断。 但这是一个奇怪的问题，只发生在python多处理环境中，任何试图将这种模型用于自己目的的人都必须认真考虑。
-n选项的手册页说
从/ dev / null重定向stdin（实际上，阻止从中读取 标准输入）。当ssh在后台运行时必须使用此选项。一个 常见的诀窍是使用它来在远程上运行X11程序 机。例如，ssh -n shadows.cs.hut.fi emacs＆amp;将 在shadows.cs.hut.fi上启动emacs，X11连接将启动 通过加密频道自动转发。 ssh 程序将放在后台。 （如果这不起作用 ssh需要输入密码或密码;另见-f 选项）。