tbox新增stackless协程支持

windoze

回复 40# yulihua49

没看见有要审核的帖子啊？

windoze

回复 40# yulihua49

另外我发现这个所见即所得的编辑器有bug，经常吃代码。你切换到纯文本编辑器就好了。

yulihua49

windoze 发表于 2017-02-07 20:57
回复 40# yulihua49

没看见有要审核的帖子啊？

18楼到26楼。审前不打招呼，审后不说明。

waruqi

回复 43# yulihua49

是的。害的我发了两遍重复的。。我还以为发失败了。。

zylthinking

回复 43# yulihua49

我非常粗的看了一下你的代码, 似乎就是 task 中分配私有存储空间;  有多少个未完成 task 就有多少个存储空间, task1 你并不能利用正在 io wait 状态从而休眠中的 task 2 的空间, 虽然这两个任务可能都泡在同一个线程上;  并不是你说的 有多少个工作线程, 就有多少个存储空间;
如过真是这样, 那么其实你的仍然是 stack full 模式; 不知理解的对不对

你的如果有些用, 那就是 task 本身是多次收发的; 因此, 你这样搞其实是将这多个收发做到了一起, 看上去好看些;

有一个 state threads 的库, 我感觉算是写的比较有意思的; 本来也想着啥时候弄一个协程库, 看到这个以后, 就熄了这心了, 老老实实用它就成了

zylthinking

回复 45# zylthinking

靠, 我看到了

       if(!rs->tc.uc_stack.ss_sp) {
            task->uc.uc_stack.ss_sp=mmap(0, use_stack_size,
                                         PROT_READ | PROT_WRITE | PROT_EXEC,
                                         MAP_PRIVATE | MAP_ANON | MAP_GROWSDOWN, -1, 0);
            if(task->uc.uc_stack.ss_sp==MAP_FAILED) {
                task->uc.uc_stack.ss_sp=NULL;
                do_work(task->sv.TCB_no); //进行你的服务,不使用AIO
                continue;
            }
        } else {
            task->uc.uc_stack.ss_sp=rs->tc.uc_stack.ss_sp;
            rs->tc.uc_stack.ss_sp=NULL;
            rs->tc.uc_stack.ss_size=0;
        }

看你的意思是, 如果这个线程分配的私有空间已经被前一个 task 认领了, 新来的 task 就不走协程模式了?

又看错了, 不是不走, 还是新分配; 也就是有一个默认的, 默认的没了, 就新分配; 说到底, 还是每个协程一个私有栈; 只不过搭配了一个内存池而已.  在成千上万个协程消耗大量内存方面, 并没有丝毫负担的减轻

zylthinking

我记得原来是能自己删除自己的帖子的啊

yulihua49

zylthinking 发表于 2017-02-08 14:38
回复 45# zylthinking

靠, 我看到了

只有极特殊的情况才会新分配。
1.线程第一次接受任务。
2.先前的任务因AIO而挂起，线程接受了新任务，才分配新空间。
确切说，栈的数量是：线程数＊2＋同时进入AIO的任务数。
实际的压力测试表明，同时进入AIO状态的任务不会很多。


正常情况，任务不会进入AIO状态。线程会把任务一直进行到底，没有机会进入再分配栈的环节。

一般的，服务器epoll等待所有的客户端，当客户端没有请求时是没有栈的。你想像下，绝大多数ATM机是空闲的，进入使用的是少数。
当一个客户端发出请求时，epoll激活线程，线程给任务分配了一个栈，在swapcontext()时转入这个栈。在do_work（）里，进行读，一般这时肯定有数据，绝大多数一次读成功，不会进入AIO状态（不发生yield）。而且以后的处理（包括向客户端应答，发送包）也不会进入AIO状态，这个栈，他一直使用到结束，return，从swapcontext（）返回，回到线程栈，协程栈交还到线程的context(rs)里。这个线程接受下一个任务时给它继续使用这个栈。

只有收发大数据才会进入AIO。一个OLTP系统，大数据的任务很少，也不可能突然成千上万的任务大数据。而且只有在低速网上传大数据才可能长时间AIO。如果真是这样的需求，那就多预备内存吧。既然你需要，分配给你也不是浪费。

zylthinking

yulihua49 发表于 2017-02-08 17:07
只有极特殊的情况才会新分配。
1.线程第一次接受任务。
2.先前的任务因AIO而挂起，线程接受了新任务， ...

不在于多少概率会分配; 而是你之前说的一堆让我觉得貌似有神技; 结果你弄这么一出;
这么说吧, 你重新分配的概率与任意一个 stackfull 的分配概率相同; 因此, 所谓成千上万协程下会比其他 协程绑定自己的私有栈 的做法省内存的说法不成立

yulihua49

zylthinking 发表于 2017-02-08 17:57
不在于多少概率会分配; 而是你之前说的一堆让我觉得貌似有神技; 结果你弄这么一出;
这么说吧, 你重 ...

计算机技术发展至今，哪有神技？

本来，一个线程池服务器，8个线程（8核）并不需要协程与AIO。
一个中心服务器处理几百辆长途汽车，每个汽车与服务器随时交互（通过3G，4G网络），一般的交易报文不长。但是有时就会出现长报文，通过低速网络。
当这些传输长报文的客户端，就会长时间占用一个线程。可以想见，有8个客户端干这事，服务器就别干别的了。

因此就需要引入AIO和协程。

原来的服务器规模不大，而且程序都是按照同步阻塞方式写的，不可能大量应用都改成异步方式。
原来8个线程8个栈，现在变成几百个协程，随着业务发展，几千个客户端也是可能的。那么，几千个context，或者叫做task，都分配栈，不管连接没连接，不管请求没请求。
我们的应用，需要栈6M，你算算需要多大内存？而且多数时间这个内存是不用的。

采用我这个办法，原来的小服务器依然胜任。同时传大文件的不超过20个任务。总共36个栈就够了，而且就是几分钟的时间。以后又都释放了。如果偶然出现很大需求可以增加对换区解决。

很多技术都是基于概率的，如虚拟存储，多任务调度，霍夫曼编码等等。

这里，就是修改了线程调度这一块，就是这140多行的代码。应用程序，do_work（）这一块，没有任何修改。服务器也不需要升级。