有道理啊，不然用signal？signal不好用也不可靠呀  
  
【 在 hgoldfish (老鱼) 的大作中提到: 】
:  QProcess 的 finished(), errorOcurrred(), stateChanged() 这些 signal 都必须有 Qt  事件循环才能被触发。
:  
:  看来实现原理是背后每个 QProcess 都有个线程在监听进程的状态，发生变化才丢到 UI 事件循环里面。通过 invokeMethod 的 QueuedConnection 方式触发上面三个 signal.
:  
--
FROM 183.179.53.*

只要跨线程了就必须有事件循环吧
【 在 hgoldfish 的大作中提到: 】
: QProcess 的 finished(), errorOcurrred(), stateChanged() 这些 signal 都必须有 Qt  事件循环才能被触发。
: 看来实现原理是背后每个 QProcess 都有个线程在监听进程的状态，发生变化才丢到 UI 事件循环里面。通过 invokeMethod 的 QueuedConnection 方式触发上面三个 signal.
--
FROM 223.104.42.*

QThread 需要接收线程有事件循环，但是 QProcess 不是啊。所以我怀疑背后还运行着一个 QThread 才会有这个 BUG

因为我拿 Qt 搞服务端开发，正常不会开事件循环，才会发现这个问题。

【 在 brucewww 的大作中提到: 】
: 什么意思，这个qprocess有什么特殊。qt的信号槽就要求接收线程有事件循环啊
--
FROM 124.72.109.*

那好像没有办法拿到这个 pipe 的 fd，没有 qt 事件循环还是处理不了。

【 在 gameplayer 的大作中提到: 】
: 并没有，至少linux版本没有额外的QThread，它用pipe来感知子进程是否退出，这一步
: 需要eventloop，没有的话这个机制就不工作了
--
FROM 183.253.146.*

DirectConnection 是直接调用了，不跨线程。
【 在 hgoldfish 的大作中提到: 】
: signal 不一定需要事件循环吧。Qt::DirectConnection 方式连接话，就是直接触发的。
:
--
FROM 103.10.85.*