在分析了各大开源协程库实现后，最终选择参考boost.context的汇编实现，来写tbox的切换内核。
在这过程中，我对boost各个架构平台下的context切换，都进行了分析和测试。
在macosx i386和mips平台上实现协程切换时，发现boost那套汇编实现是有问题的，如果放到tbox切换demo上运行，会直接挂掉。
在分析这两个架构上，boost.context切换实现问题，这边先贴下tbox上的context切换demo，方便之后的讲解：
继续阅读 »
协程现在已经不是个新东西了，很多语言都提供了原生支持，也有很多开源的库也提供了协程支持。
最近为了要给tbox增加协程，特地研究了下各大开源协程库的实现，例如：libtask, libmill, boost, libco, libgo等等。
他们都属于stackfull协程，每个协程有完整的私有堆栈，里面的核心就是上下文切换(context)，而stackless的协程，比较出名的有protothreads，这个比较另类，有兴趣的同学可以去看下源码，这里就不多说了。
那么现有协程库，是怎么去实现context切换的呢，目前主要有以下几种方式：
使用ucontext系列接口，例如：libtask
使用setjmp/longjm
继续阅读 »
gateway的初步想法
已有一套基于epoll event的框架， 打算gateway在这个基础上， 配合boost::asio做。雏形先做个socket proxy出来.
TODO:
1，设计一个AsioClient类， 它是gw到后端具体gs的连接封装. AsioClient类想到2个方案：
a, 在原来的面向玩家的SClientSocket类和AsioClient类之间做friend， asio_write, asio_read, asio_connect的callback中， 回调SClientSocket中的对应Write, Read达到与epoll 事件打通， 因此打通玩家到后端gs的proxy
继续阅读 »
tbox之前提供的stackfull协程库，虽然切换效率已经非常高了，但是由于每个协程都需要维护一个独立的堆栈，
内存空间利用率不是很高，在并发量非常大的时候，内存使用量会相当大。
之前考虑过采用stacksegment方式进行内存优化，实现动态增涨，但是这样对性能还是有一定的影响，暂时不去考虑了。
最近参考了下boost和protothreads的stackless协程实现，这种方式虽然易用性和灵活性上受到了很多限制，但是对切换效率和内存利用率的提升效果还是非常明显的。。
因此，我在tbox里面也加上了对stackless协程的支持，在切换原语上参考了protothreads的实现，接口封装上参考了boost的设计，使得更加
继续阅读 »
工厂类回收资源和夸线程回调时对象是否还存在判断
虽然大多数逻辑都在单线程里实现， 但是不能避免的是一些IO阻塞类型逻辑， 不得不放入子线程里执行，当IO完成后boost:bind(callback, arg1, arg2 ...) 放入主线程队列内执行callback, 但是问题是，假如callback指向的对象函数的对象， 已经销毁了， 这时候就无法判断对象是否还存在了，不判断就会core dump.
继续阅读 »
新特性
支持make进行直接编译（会去自动下载xmake进行构建）
在平台库中，添加切换context上下文接口（参考boost.context实现原理进行重写，并对部分架构进行优化）
新增跨平台协程模块（支持i386, x86_64, arm, arm64），提供更加易用的高性能并发编程模式
新增基于协程的各种服务器开发实例（包括：简单轻量的http服务器，爬虫。。）
新增poller轮询器接口，实现对epoll, poll, kqueue, select的封装，逐步取代老的aiop接口
新增mbedtls ssl库接口支持，目前已支持：openssl, polarssl, mbedtls
tbox所有stream, socke
继续阅读 »