yyzybb537
yyzybb537
不需要用户主动dispatch了，底层会自动做好这个事。 libgonet还没适配3.0，还需要使用2.9
go可以指定调度器，不指定时的规则是这样的： 1.如果在协程中创建新协程，会加入当前协程所在的调度器 2.协程外创建，会加入到默认的全局调度器里
用goStart 另起线程去调度就好了
TimedPush
可以使用write_chan_.Close()
> 其实在c++世界里, 跨线程调度的协程是非常危险的, 在实际业务逻辑代码层, 反而不如有规划的合理安排资源, 对协程底层如何调度缺乏理解和本身编码能力不是非常丰富的开发人员来讲, 最后对项目本省更加混乱. > > 目前为了充分的利用CPU与多核多线程的优势同时又为了获得coroutine这种可以用户态控制的切入切出的能力, 只能在自己公司又经验的人自己开发一套. 自己系统内部使用. 目前看到能工作且工作很好的基本都是这样一类. bthread/ libgo 或者其他的. 单从使用的安全性上讲, 各种这些M:N(带或者不带任务跨线程调度机制)的各种库,远远达不到“安心”用的状态. 里面都有各种个样的需要避免的东西, 而这些使用者是不知道的. 很多甚至开发者自己也罗列不出来, 只有别人出了问题. 提到了之后, 开发者才会说:“哦, 这里因为xxx的原因,不能这样调度" 首先请明确“安心用”和“无脑用”的区别，即使是系统syscall这样级别的东西，也是不能无脑用的，你也要了解很多API细节（比如signal处理函数要可重入），不可能在对底层一无所知的情况下hold住大项目。 但是系统syscall是可以"安心"用的，这个安心的前提是经过充分测试，大多数场景不会出现问题。 在我看来，有充分测试的或商用项目检验过的开源软件都是可以“安心”用的，因为大多数场景下已经不会有bug了，即使遇到偶发的bug使用者都可以自主fix。 你认为的跨线程调度协程的危险性其实是来源于多线程编程的复杂性，近乎9成的程序员都是hold不住这种复杂性的，但是有些场景下又不得不使用多线程来提升性能。 libgo把多线程编程的复杂性都封装在了CSP模型的背后，对程序员屏蔽了这些细节，是用来降低开发门槛的。协程本身带来的技术细节还是比较少的，是远远低于多线程编程和异步编程的复杂性的，总体而言还是利大于弊的！
先跑单线程的试试看。 libgo的Start设置的是协程调度器的线程数量，网络线程数量在其他地方设置
更新后参加sample5
goStart是不阻塞当前线程的