在TaskScheduler类中管道无实际作用？

[wusopp]

您好：在TaskScheduler类中 _wakeupPipe->write(&event, 1);和_wakeupPipe->read(event, 1); 应该起事件触发作用吧， 但代码中注释掉也不影响实际功能，这点比较困惑

[PHZ76]

你好，是的，这个主要是用于唤醒EventLoop执行触发事件。在RtspServer那边通过TriggerEvent来转发音视频数据

[wusopp]

你好，是的，这个主要是用于唤醒EventLoop执行触发事件。在RtspServer那边通过TriggerEvent来转发音视频数据

我采用的是win调试的，未在linux进行调试， 然后采用test_echo_server.cpp进行测试的，其中EventLoop::loop()调用TaskScheduler::start()进行循环处理事件（handleTriggerEvent），调试上看，每次addTriggerEvent 事件只需要压入栈中，然后handleTriggerEvent事件时，再从栈中弹出即可，并不需要PIPE进行唤醒触发。

您说的 “用于唤醒EventLoop执行触发事件” ，可否是指调用_wakeupPipe->write时，如果不进行wake()，会卡在这里呢？还是会出现什么样的异常呢？

对这部分很困惑，希望大佬能多多指教，谢谢了

[PHZ76]

EventLoop的在window下使用select做IO复用, 实际上我设置了一个超时时间，所以EventLoop在没有任何事件的情况下也不会真的一直阻塞。wakeupPipe在window下使用socket模拟的，并且由select监听，所以write之后select会检测到读事件触发，如果没有进行wake读走数据, select会一直触发读事件，而且pipe的底层缓冲区也会满的，最后会造成wirte失败。 我也不是大佬。。。大家互相学习，交流讨论。

[wusopp]

EventLoop的在window下使用select做IO复用, 实际上我设置了一个超时时间，所以EventLoop在没有任何事件的情况下也不会真的一直阻塞。wakeupPipe在window下使用socket模拟的，并且由select监听，所以write之后select会检测到读事件触发，如果没有进行wake读走数据, select会一直触发读事件，而且pipe的底层缓冲区也会满的，最后会造成wirte失败。 我也不是大佬。。。大家互相学习，交流讨论。

我按照你说的进行调试下看看，从这部分代码学到了不少知识，感谢感谢

[wusopp]

EventLoop的在window下使用select做IO复用, 实际上我设置了一个超时时间，所以EventLoop在没有任何事件的情况下也不会真的一直阻塞。wakeupPipe在window下使用socket模拟的，并且由select监听，所以write之后select会检测到读事件触发，如果没有进行wake读走数据, select会一直触发读事件，而且pipe的底层缓冲区也会满的，最后会造成wirte失败。 我也不是大佬。。。大家互相学习，交流讨论。

已经完全搞懂这部分了，再次多谢

如果有后来者看到这里，也有困惑的话，建议把延时时间调长一点，比如5秒，结合作者上面的回复，很容易看到其中的区别