- 主题:gcc是不是symmetric transfer的支持有问题？
你再想想，你切换栈的时候，堆里指向栈的指针怎么办？
【 在 ylh1969 的大作中提到: 】
: ucontect有用户栈呀，任务切换最最重要的，就是切换栈呀！
--
FROM 110.84.121.*
你为啥能打出63+1出来。这个 mgc.
既然已经是 63+1 位计算机，你就没必要折腾这个切换栈的功能。
而在 32 位计算机下，ucontext 这种浪费内存的玩法也约等于没用。
【 在 ylh1969 的大作中提到: 】
: 现在都是64位机了吧，资源不是问题。
: stackless没有可用性。
: 我的解决办法是在多线程协程服务器中，只有发出了服务请求并被受理的客户端context，才分配栈，栈的生命期，只存在于本次服务期间，一旦服务完成，context进入等待状态前，收回它的栈。只有活动任务占用栈，等待状态的任务不占用栈。
: ...................
--
修改:hgoldfish FROM 110.84.121.*
FROM 110.84.121.*
这些都由那4个函数操作，它就是操作这个的。
【 在 hgoldfish 的大作中提到: 】
: 你再想想，你切换栈的时候，堆里指向栈的指针怎么办？
:
--
FROM 221.221.55.*
堆啊！
那几个函数只管栈，不管堆的。
ucontext 在现在 63+1 位时代是可用的没错，但你切换栈内存的做法会出问题的。
【 在 ylh1969 的大作中提到: 】
: 这些都由那4个函数操作，它就是操作这个的。
--
修改:hgoldfish FROM 110.84.121.*
FROM 110.84.121.*
32位机一样用。
包装后的协程库反而难解决这个问题。
【 在 hgoldfish 的大作中提到: 】
: 你为啥能打出63+1出来。这个 mgc.
: 既然已经是 63+1 位计算机，你就没必要折腾这个切换栈的功能。
: 而在 32 位计算机下，ucontext 这种浪费内存的玩法也约等于没用。
: ...................
--
FROM 221.221.55.*
不会的 c++20 stackless coroutine 没这个内存管理的问题。
【 在 ylh1969 的大作中提到: 】
: 32位机一样用。
: 包装后的协程库反而难解决这个问题。
--
修改:hgoldfish FROM 110.84.121.*
FROM 110.84.121.*
不会，都调试好了，运行过了，稳定可靠，资源可控。
【 在 hgoldfish 的大作中提到: 】
: 堆啊！
: 那几个函数只管栈，不管堆的。
: ucontext 在现在 63+1 位时代是可用的没错，但你切换栈内存的做法会出问题的。
: ...................
--
FROM 221.221.55.*
敢在协程里调用数据库吗？
【 在 hgoldfish 的大作中提到: 】
: 不会的 c++20 stackless coroutine 没这个内存管理的问题。
:
--
FROM 221.221.55.*
这是因为你用在自己项目里面可控啊。
如果是第三方开发者，没弄清楚你这个机制，在堆里面引用了栈内存。这时候就容易出事。
所以在 c/c++ 下玩这种栈内存复用是很危险的。
你要是搞 java/python 的栈内存切换倒是没问题。事实上 python-gevent 切换协程的时候，也会切换内存，就是你这个思路。但那是因为人家 python 的栈和 c/c++ 的栈不是一回事。所有对象占用的内存都被 python 给管理起来了才能这样玩。但 c/c++ 不是。
【 在 ylh1969 的大作中提到: 】
: 不会，都调试好了，运行过了，稳定可靠，资源可控。
--
FROM 110.84.121.*
这就是 await 这个语法传染性的问题了。
和内存管理不是一回事。
反正我也不看好 c++20 的协程。但同时也指出你用 ucontext 没问题，只是额外搞的这个栈内存切换是在风险的。
【 在 ylh1969 的大作中提到: 】
: 敢在协程里调用数据库吗？
--
修改:hgoldfish FROM 110.84.121.*
FROM 110.84.121.*