- 主题:gcc是不是symmetric transfer的支持有问题？
别弄这些没用的了。不够debug的呢。
要么别用coroutine，要么，直接使用libc里的协程函数。
makecontext，getcontext，setcontext，swapcontext。主要就这几个函数，概念基础，所需的资源自己控制，细节自己清楚，用起来简单，debug相对容易。
我猜所有协程工具都是对这几个函数的包装，用到的机制和资源不清楚，可能使用过程会遇到麻烦。
基础协程函数stack的尺寸是你自己设定的，不够用自己调整。
【 在 allegro 的大作中提到: 】
: 自己写了一些带coroutine的for循环，发现stackoverflow。
: 怀疑是不是有symmetric transfer的问题，对着Lewis Baker的那篇博文比较，的确如此。
: 改成symmetric transfer的形式后，仍然crash，导致自我怀疑好几天。
: ...................
--
修改:ylh1969 FROM 221.221.55.*
FROM 221.221.55.*
ucontext不是回调啊，就是coroutine呀！
一共4个函数，每个功能都极其简单，非常好理解。
由于资源是你自己管理的，这部分代码会有一些。有啥问题自己清楚。
我的体会就是在切换过程，资源的交接，要想好，debug费点劲的就在这里。
【 在 allegro 的大作中提到: 】
: 不能这么说。我写了太多回调，又臭又长。接触到原生coroutine后，才觉得这真是个好东西。写出来的代码逻辑清晰，代码长度极大缩短。
: - 来自 水木社区APP v3.5.7
--
修改:ylh1969 FROM 221.221.55.*
FROM 221.221.55.*
现在都是64位机了吧，资源不是问题。
stackless没有可用性。
我的解决办法是在多线程协程服务器中，只有发出了服务请求并被受理的客户端context，才分配栈，栈的生命期，只存在于本次服务期间，一旦服务完成，context进入等待状态前，收回它的栈。只有活动任务占用栈，等待状态的任务不占用栈。
比如ATM服务器，那些呆着的都没有栈。
即使操作的，没有与服务器交互的期间也没有。只有在与服务器一去一回的瞬间，这个任务才有栈。这期间它可以以同步方式进行异步IO操作，也可以调动数据库进行业务。stackless,你敢玩数据库？还有其他第三方软件接口，人家需要多少栈你管不着，你的任务，分配给人家足够的栈。
【 在 hgoldfish 的大作中提到: 】
: 这一套要是真的那么好用早就流行起来了。但事实上是没有。
: ucontext 这几个函数是不跨平台的，在 windows 下不能用也就算了，连 android 同样是 linux 内核也用不了。
: 而且因为它申请的 mmap(MAP_GROWDOWN | MAP_STACK) 内存。一次申请 8MB 的话，在以前 32 位机器里，只有 2GB 的内存空间经常不够用。
: ...................
--
修改:ylh1969 FROM 221.221.55.*
FROM 221.221.55.*
ucontext有用户栈呀，任务切换最最重要的，就是切换栈呀！只不过栈是你管理的，所以才可以采取各种各样措施解决栈空间问题，你也可以搞你的栈空间管理呀，我只是抛砖引玉。
【 在 hgoldfish 的大作中提到: 】
: 你这个玩法只能用在自己的项目里。
: 因为你这个框架没法控制别人堆里有个指针指向栈啊！
:
--
修改:ylh1969 FROM 221.221.55.*
FROM 221.221.55.*
这些都由那4个函数操作，它就是操作这个的。
【 在 hgoldfish 的大作中提到: 】
: 你再想想，你切换栈的时候，堆里指向栈的指针怎么办？
:
--
FROM 221.221.55.*
32位机一样用。
包装后的协程库反而难解决这个问题。
【 在 hgoldfish 的大作中提到: 】
: 你为啥能打出63+1出来。这个 mgc.
: 既然已经是 63+1 位计算机，你就没必要折腾这个切换栈的功能。
: 而在 32 位计算机下，ucontext 这种浪费内存的玩法也约等于没用。
: ...................
--
FROM 221.221.55.*
不会，都调试好了，运行过了，稳定可靠，资源可控。
【 在 hgoldfish 的大作中提到: 】
: 堆啊！
: 那几个函数只管栈，不管堆的。
: ucontext 在现在 63+1 位时代是可用的没错，但你切换栈内存的做法会出问题的。
: ...................
--
FROM 221.221.55.*
敢在协程里调用数据库吗？
【 在 hgoldfish 的大作中提到: 】
: 不会的 c++20 stackless coroutine 没这个内存管理的问题。
:
--
FROM 221.221.55.*
swapcontxt(uc ，tc）；
把任务从uc切换到tc，假定uc是堆，tc是栈，
那就是堆里的栈保存在uc，线程栈在tc，下一次swap就换回来。
【 在 hgoldfish 的大作中提到: 】
: 你再想想，你切换栈的时候，堆里指向栈的指针怎么办？
:
--
修改:ylh1969 FROM 221.221.55.*
FROM 221.221.55.*
使用现成的轮子，问题就在这里，我不知道stack_manager()里边干了啥，出了问题就很难找。
如果这个函数是自己写的，不会暴露给用户，他们理解不了这里边想干啥。
我会把整个异步IO协程框架封装起来，搞好一切资源后，调用应用函数，应用程序员只写应用逻辑，至于是谁，什么机制，进程？线程？协程？来调用，不用管。当然，会告诉他们运行环境及注意事项。资源参数配置他们可以直接配置文件干。
【 在 hgoldfish 的大作中提到: 】
: 举个例子:
: void my_coroutine() {
: Task task;
: ...................
--
修改:ylh1969 FROM 221.221.55.*
FROM 221.221.55.*