- 主题:光有协程不够吧？
你说的是对的啊。用协程的就不要用 thread local 了。
我今天突然发现协程方案的一个好处是在协程里面申请内存可以更频繁地使用栈内存。也算一种加速。
【 在 allegro 的大作中提到: 】
: 感觉多线程协程thread_local基本废了。
: 除非语言实现支持，不同线程驱动同一协程，在切换时，把thread_local的寻址也切换一下。
: Correct me if I am wrong.
: ...................
--
FROM 110.81.0.*
也不是完全不能用，thread_local保存指针，所以可能切换线程后更新指针
【 在 allegro (静水流深) 的大作中提到: 】
: 感觉多线程协程thread_local基本废了。
: 除非语言实现支持，不同线程驱动同一协程，在切换时，把thread_local的寻址也切换一下。
:
: Correct me if I am wrong.
--
FROM 117.136.68.*
tls要是不处理，不管切换线程的概率有多低，一旦发生就是bug啊
【 在 ylh0315 (ylh0315) 的大作中提到: 】
: IO时偶然会切换线程，根本不会对实际效果有啥影响。
: 【 在 ensonmj 的大作中提到: 】
: : 也不是完全不能用，thread_local保存指针，所以可能切换线程后更新指针
:
--
FROM 183.213.128.*
负载均衡算法弄好就行了。很简单的，看谁不忙才把任务给它。
nginx 做这个算法不容易，因为不知道各个进程的忙碌程度。但协程算法很容易，只要在事件循环里面计算一下，其它线程马上可以取到这个值。
【 在 ylh0315 的大作中提到: 】
: 负载均衡很不充分哦！我这个几乎可以把所有的核用到100%。
: 一个指标可以看到负载均衡的效果：
: 最大响应时间与平均响应时间之比，越小越好。
: ...................
--
FROM 183.253.143.*
你没看明白吧。thread_local 切一下就是 BUG 了。
【 在 ylh0315 的大作中提到: 】
: 切换有啥关系，换个核呗。反正IO会等待很长时间，不在乎这一点点。之前的核可以及时为其他任务服务也比在这里死等强。
: 我的设计是尽量不切换。IO都是先干一把，干不完再yield。
--
FROM 183.253.143.*
【 在 hgoldfish 的大作中提到: 】
: 负载均衡算法弄好就行了。很简单的，看谁不忙才把任务给它。
: nginx 做这个算法不容易，因为不知道各个进程的忙碌程度。但协程算法很容易，只要在事件循环里面计算一下，其它线程马上可以取到这个值。
:
负载均衡涉及线程间通信，还要知道线程是不是挂起，要不要唤醒，开销也不小
--
FROM 223.160.131.*
切换后tls状态就不对了啊…
【 在 ylh0315 (ylh0315) 的大作中提到: 】
: 切换有啥关系，换个核呗。反正IO会等待很长时间，不在乎这一点点。之前的核可以及时为其他任务服务也比在这里死等强。
: 我的设计是尽量不切换。IO都是先干一把，干不完再yield。
: 【 在 ensonmj 的大作中提到: 】
: : tls要是不处理，不管切换线程的概率有多低，一旦发生就是bug啊
--
FROM 117.136.68.*
tls的是指针，指向携程独占数据是不是就ok了？
【 在 ylh0315 (ylh0315) 的大作中提到: 】
: 即使是单线程协程，也不行。threadlocal是线程独享数据，但是成为协程共享数据。你这个tls不支持协程。
: 【 在 ensonmj 的大作中提到: 】
: : 切换后tls状态就不对了啊…
:
--
FROM 223.104.210.*
那东西得随运行库变化吧
从thread local变成fiber local
【 在 allegro 的大作中提到: 】
: 感觉多线程协程thread_local基本废了。
: 除非语言实现支持，不同线程驱动同一协程，在切换时，把thread_local的寻址也切换一下。
: Correct me if I am wrong.
: ...................
--
FROM 123.112.20.*
【 在 ylh0315 的大作中提到: 】
: 单epoll队列+线程池+协程，根本不需要任何算法，自动就是充分均衡的。
: 缺点是，一个队列，每次激活一个线程需要3～7微秒，平均算5微秒，每秒20万次激活，是极限了，与核数无关。
这么长的时间，还不如直接使用线程了，linux线程切换之前的数据是2微秒，我在自己13900k机器测试切换350ns
--
FROM 61.48.14.*