将os.runv/os.iorunv改为pipe

[ChrisCatCP]

原来的实现是用file来实现的 是否可以考虑改成pipe?

[waruqi]

暂时不考虑，性能反而可能会更慢，而且稳定性，兼容性也不一定能保证。

1. 首先是性能，stdout/stderr 那点输出量原本就不大，写 file 也不会有多少 io 损耗，但是你改成 pipe，就要额外单独开个两个协程去 read/write ，要走协程调度，甚至每个 os.iorunv 调用，都要单独开个两个协程。 占用更多协程和调度资源，要是并发一高，这个性能未必比 file 的方式快，反而要频繁 wait 对应的协程退出，和创建新协程。而一个 os.iorunv 要同时等待 process, read pipe, write pipe 三路协程的退出，才算完整退出，多少也会有些延迟，尤其是并发高的时候。

remote build 里面目前就有一份用了 pipe 的实现，可以看下：

xmake/xmake/modules/private/service/remote_build/server_session.lua

Line 252 in c1802f7

scheduler.co_group_begin(group_name, function (co_group)

不过只是开了一路，所以没啥问题。

而且，目前 xmake 的调度，要同时调度 pipe, socket 和 process，在 windows 上， pipe/socket 走的 iocp ，process 走的是独立线程。

调度等待机制实现上没法像 epoll 那样完全一个 wait fd list 搞定所有，原本常规状态仅仅只需要等待 process list，非常简单高效，现在还要 pipe 掺和进来去 wait ，两路不同的 wait list 需要走线程同步，多少也会增加延迟。

2. 关于兼容性，走 file 的兼容性肯定是最通用稳妥的。

[waruqi]

而且走文件，也是在独立子进程中去写 stdout 到 file， xmake 只管 wait process 完成就行，并不会慢多少，也不影响 xmake 主进程执行，实现还更简单维护，不容易出错

[ChrisCatCP]

我其实有实现 确实发现不是很好用