- 主题:gcc是不是symmetric transfer的支持有问题？
我不会这么用。
我的task里保留的是uc(user context 协程栈）和tc(thread context，线程栈)，两套环境的动态资源，想切哪个切哪个。
你说的这些，man一下ucontext应该有完整说明。
【 在 hgoldfish 的大作中提到: 】
: 举个例子:
: void my_coroutine() {
: Task task;
: ...................
--
修改:ylh1969 FROM 221.221.55.*
FROM 221.221.55.*
就问你在stackless协程里能调用数据库吗？
玩ATM服务器,IO完了就是数据库，数据库完了就是IO,你咋整？
【 在 hgoldfish 的大作中提到: 】
: 这就是 await 这个语法传染性的问题了。
: 和内存管理不是一回事。
: 反正我也不看好 c++20 的协程。但同时也指出你用 ucontext 没问题，只是额外搞的这个栈内存切换是在风险的。
: ...................
--
修改:ylh1969 FROM 221.221.55.*
FROM 221.221.55.*
我干完这个事还没有风云呢。
【 在 hgoldfish 的大作中提到: 】
: 你做的这个和云风那个类似。知乎上面有个分析云风 coroutine 库的系列文章，你可以去看一下。里面有很多分析。
:
--
FROM 221.221.55.*
如果它也搞动态栈分配，那是英雄所见略同。
定义好资源的生命期，处理好资源的投放和回收，实践证明这个方案是可靠的。
【 在 hgoldfish 的大作中提到: 】
: 有没有云风不重要。关键是你俩的实现是一样的。
:
--
修改:ylh1969 FROM 221.221.55.*
FROM 221.221.55.*
我的还真叫task。但是不会交给搞不清楚的函数去管理它的资源。不会这么用，也不会出现你说的问题。
争论的关键是，我认为，stackless没有实用价值。动态栈分配是个抛砖引玉。你也不要拘泥于stackless，可以思考更好的方法，届时再讨论。
【 在 hgoldfish 的大作中提到: 】
: 唉。你还是没看明白。把这个 Task 改成 User 吧。
: void my_coroutine() {
: User user;
: ...................
--
修改:ylh1969 FROM 221.221.55.*
FROM 221.221.55.*
初期的调试，确实挺艰苦，尤其是在注册事件和swap期间，
如果swap未完成，事件就触发了，另一个线程抢到了这个task，就乱套了。
所以调试了几个月，才把所有临界区处理好，处理的结果是系统很稳定，可以通过长时间的混合模型压力测试。
长短延时网络，高低网速网络，横跨太平洋的国际网络的压力测试。
【 在 hgoldfish 的大作中提到: 】
: stackless 和 stackful 有各自的应用场景。那些不重要。
: 我是跟你说啊，你那种切换栈空间的玩法是很危险的。
: 性能怎么样啊，能不能实现目标啊这些先别说。。至少先别搞出崩溃啊。
: ...................
--
修改:ylh1969 FROM 221.221.55.*
FROM 221.221.55.*
正因为这个模型调试困难，所以做的是交易中间件框架，类似TUXEDO,比它强。就是RPC服务器，各种应用写应用逻辑就好，作为函数插件插入框架，由客户端调用。框架提供的运行环境可以是各种模式，多线程，进程，协程都可能。同步异步都可能，不需要知道些概念，用就好。
干啥都行，做ATM,售票，社会服务系统。小企业网络业务。。。
【 在 hgoldfish 的大作中提到: 】
: stackless 和 stackful 有各自的应用场景。那些不重要。
: 我是跟你说啊，你那种切换栈空间的玩法是很危险的。
: 性能怎么样啊，能不能实现目标啊这些先别说。。至少先别搞出崩溃啊。
: ...................
--
修改:ylh1969 FROM 221.221.55.*
FROM 221.221.55.*
野指针是不可能出现的。
再谈效率，就单一任务而言，协程效率肯定比同步IO低得多，事件激发后就是一个栈分配，经过一系列判断才swap到应用函数，当他使用IO时会被yield，线程会被剥夺，被别人加塞，resume还要干一大堆事，所有过程还有一大堆日志。。。。。但是，必须这么做，不然，你占着茅坑不拉屎，系统吞吐量就完蛋了。
【 在 hgoldfish 的大作中提到: 】
: stackless 和 stackful 有各自的应用场景。那些不重要。
: 我是跟你说啊，你那种切换栈空间的玩法是很危险的。
: 性能怎么样啊，能不能实现目标啊这些先别说。。至少先别搞出崩溃啊。
: ...................
--
FROM 221.221.55.*
那几个函数只管ucontext里的栈，不管来自哪里。
【 在 hgoldfish 的大作中提到: 】
: 堆啊！
: 那几个函数只管栈，不管堆的。
: ucontext 在现在 63+1 位时代是可用的没错，但你切换栈内存的做法会出问题的。
: ...................
--
FROM 221.221.55.*
动态栈空间管理，就是用mmap呀，定义好生命周期和资源投放回收，临界区（4个月的debug，就是处理临界区）处理这些，就没问题，已经投产使用啦。框架调好了，各种应用都没问题。
单线程协程没有临界区，简单多了。你不妨试试。
临界区就是一个任务还没有swap完成，另一个线程就拿到这个任务并企图处理它。
栈切换不是我的事，是那4个函数干的。
【 在 hgoldfish 的大作中提到: 】
: 嗯。没错，只管栈的。这本来也没问题。ucontext 当然是没问题的，不然早就从 POSIX API 里面删掉了。
: c++20 则是把内存申请在堆里面。这就是为啥 c++20 是安全可靠的，而你弄的那一套栈切换是有问题的。如果那么简单，开源世界早就流行了。
: 再强调一遍，ucontext 没问题。是你弄的栈切换有问题。
: ...................
--
修改:ylh1969 FROM 221.218.60.*
FROM 221.218.60.*