参照着模拟线程的代码，稍作包装，写出了这个协程代码，我只在linux(64)上做了测试
协程不应该使用互斥体之类的东西，这会影响性能。为了性能，我也尽量减少了与内核的交互
因为是学习性质，所以我也不想搞得太复杂
如果要兼容32位和64位，还要兼容windows和linux，这将要改变大量的代码，插入大量的宏判定，这不是我想要的
后序我又参照着线程池的代码，拓展出了协程池，但是我设计得并不好，他的易用性远不如协程
这个协程安全性为 0 ，不带任何保护。为了适应代码我关闭了ASLR(这会使得每次程序加载的虚拟地址不固定)，同时也没有随机cookie的保护 (这不是重点，重点是模拟)
我并未测试try catch语句，也许会有问题，毕竟操作系统切换线程的时候是保存了对应的异常链表的，而我什么都没做 (我对异常链表了解太少了，菜是原罪)
我没有在协程中加入任何线程安全的东西，所以请不要用多个线程控制一个协程块
我有写两个test文件，一个是协程的测试，另一个是协程池的测试 (因为懒得折腾Cmake，所以写成这个样子)
用户可以通过scheduling来让出执行权，也可以通过sleep和<suspend，resume>控制执行
创建协程后必须通过scheduling来调度协程，否则永远不会进入创建好的协程，永远只会在主协程中(cid = 0)
当然也能通过加锁Coroutine::scheduling函数，然后通过其他线程调度，这样并不好
或者把代码中所有主动调用Coroutine::scheduling函数的地方删掉，启动一个线程来专门执行调度，但为什么需要开一个线程专门调度协程？
我想协程是由用户自己控制的，所以照搬线程池的套路果真不是太好 (线程池的代码是大佬的思路)
协程最占用资源的地方就是它的堆栈，我给它设定的大小是0x80000，当然也可以再大一些
所以创建一个协程的时候应该是写一个内存池，用内存池给协程分配资源，这样就够了，仿造线程池写的真的不是很好
我也有考虑写成C语言的代码，但是如果协程C++那样每个函数传一个类似this的指针，那样毫无意义
如果为了减少这样恶心的参数，将变量声明为全局的，就要考虑用户在多个线程内使用协程的问题
为了全局变量的安全，就必须使用互斥体之类的东西保证数据安全，这是与内核交互，会影响性能，那么协程的意义又何在？
尝试加入一个小东西，而不是简单的例子来验证协程
这个httpd运行流畅，基本没有问题