tbox内部的所有io操作都是原生支持协程的，可以在线程和协程间任意切换，内置基于轮询的io调度器（epoll, kqueue等，后续还会支持iocp）.
我们在socket操作的时候，只需要像平常顺序编程那样操作就可以实现异步并发收发数据。
这里先给个简答的文件服务器的例子，可参考下，代码非常简单：
文件接收服务器
这个文件服务器的功能很简单，就是不停的接收连接，然后开新协程，进行文件传输。
通过协程，从原始socket写起，也只需要不到100行代码，就可以实现一个高并发的文件服务器。
此处用到了tb_socket_sendf直接对文件句柄操作，发送到socket，内部使用sendfile实现，不需要再上层开buffe
继续阅读 »
TBOX封装了一套跨平台的异常捕获实现，来模拟windows的seh异常处理功能，而且是线程安全的。
在linux/mac下的实现
使用signal 捕获异常信号
使用sigsetjmp保存现场寄存器和信号掩码，出现异常后使用 siglongjmp 跳转到异常处理过程，并恢复状态
使用线程局部存储维护 sigjmpbuf 寄存器现场状态堆栈，保证多线程安全，并且可以实现多层嵌套捕获处理。
在windows下的实现
这个就不用多说了，在vs下直接用 try、except 关键字就行了，如果在mingw下编译， 通过 setjmp实现也很方便。
具体使用
注： 由于使用setjmp 进行寄存器现场保护， 如果使用整型局部变量，
继续阅读 »
TBOX提供了各种常用算法，对容器中的元素进行各种操作，这里主要介绍下排序和查找算法。
排序算法目前支持如下几种：
快速排序：tb_quick_sort
堆排序： tb_heap_sort
插入排序：tb_insert_sort
冒泡排序：tb_bubble_sort
并且提供通用的tb_sort接口，对各种排序算法进行自动适配，使得任何情况下，性能都是最优的。
例如：
对具有随机迭代特性的容器，采用快速排序来优化
对具有随机迭代特性，并且是超大规模的容器，采用堆排序
对只能线性迭代的容器采用冒泡排序
继续阅读 »
stl的容器库非常强大，但是为了要兼容各种元素类型，采用了模板进行泛化，这样的好处就是使用非常的方便，但是编译器会对使用到的每种类型都进行一遍实例化，用的类型太多的话不仅影响编译速度而且生成的可执行文件也很冗余。
因此，TBOX在设计容器架构的时候，引入tb_item_func_t类型，来设置容器使用的成员类型，这样在实现容器通用性的同时，也不会产生过的冗余，而且容器接口操作上，同样相当的便利。
可以先看个简单使用哈希的例子：
```c
/* 初始化hash, 哈希桶大小8
* 键：大小写敏感字符串
* 值：long整型
*/
tb_hash_map_ref_t hash = tb
继续阅读 »
stl的容器库常用模式就是将容器、迭代器和算法的进行分离，容器专于存储，迭代器负责枚举，这样互相独立好处多多。
因此TBOX也借鉴了这种模式，不同的是没用模板，仅仅用了c语言来实现。容器库里面的大部分容器都是继承自迭代器的，所以迭代起来相当的方便。
下面先看个迭代器使用的例子：
继续阅读 »
线程局部存储(Thread Local Storage，TLS)主要用于在多线程中，存储和维护一些线程相关的数据，存储的数据会被关联到当前线程中去，并不需要锁来维护。。
因此也没有多线程间资源竞争问题，那如何去实现TLS存储呢，主要有以下几种方式：
gcc和clang的__thread修饰符
windows下msvc的__declspec(thread)修饰符
pthread库pthread_setspecific和pthread_getspecific接口
windows下的TlsSetValue和TlsGetValue
thread和declspec(thread)的使用
其中thread和declspec(thread)
继续阅读 »
原子操作，线程间交互数据最细粒度的同步操作，它可以保证线程间读写某个数值的原子性。
由于不需要加重量级的互斥锁进行同步，因此非常轻量，而且也不需要在内核间来回切换调度，效率是非常高的。。
那如何使用原子操作了，各个平台下都有相关api提供了支持，并且向gcc、clang这些编译器，也提供了编译器级的__builtin接口进行支持
windows的Interlockedxxx和Interlockedxxx64系列api
macosx的OSAtomicXXX系列api
gcc的__sync_val_compare_and_swap和__sync_val_compare_and_swap_8等__builtin接口
x86和x86_
继续阅读 »
此版本主要修复一些稳定性问题。
更多使用说明，请阅读：文档手册。
项目源码：Github, Gitee.
改进
改进add_files，支持对files粒度进行编译选项的各种配置，更加灵活。
从依赖的target和option中继承links和linkdirs。
改进target.add_deps接口，添加继承配置，允许手动禁止依赖继承，例如：add_deps("test", {inherit = false})
移除tbox.pkg二进制依赖，直接集成tbox源码进行编译
Bugs修复
修复目标级联依赖问题
修复target:add和option:add问题
修复在archlinux上的编译和安装问题
修复/ZI的兼容性
继续阅读 »
最近在xmake中，用lua的协程实现了多任务编译，效果还是不错的，不过后来发现一个问题：
如果所有编译进程都在处理编译，没有退出的时候，xmake的lua主进程会不断地在这些任务间，不停的切换轮询进程的状态，但是有没有机会执行其他任务，导致cpu过高，抢占了编译进程的cpu时间。。
那如果在等不到完成的进程时候，加入sleep等待呢，又会导致编译速度变慢，没法合理利用cpu。。
因此，为了解决这个问题，我打算扩展下lua的接口，实现了一个跨平台的多进程等待接口: process.waitlist 实现多个未完成进程的同时等待，让出xmake主进程的cpu时间，给其他编译进程充分利用
xmake中的lua代码如下：
```
继续阅读 »
Bloom Filter是由Bloom在1970年提出的一种快速查找算法，通过多个hash算法来共同判断某个元素是否在某个集合内。可以用于网络爬虫的url重复过滤、垃圾邮件的过滤等等。
它相比hash容器的一个优势就是，不需要存储元素的实际数据到容器中去来一个个的比较是否存在。
只需要对应的位段来标记是否存在就行了，所以想当节省内存，特别适合海量的数据处理。并且由于省去了存储元素和比较操作，所以性能也比基于hash容器的高了很多。
但是由于bloom filter没有去比较元素，只通过多个hash来判断唯一性，所以存在一定的hash冲突导致误判。误判率的大小由hash函数的个数、hash函数优劣、以及存储的位空间大小共同决定。
继续阅读 »