@lakehylia #19 其实并没有，还是很谨慎的，主要是我开的是云南这边的盘山公路，路窄弯又多，出的小毛病多一些，那次撞车也是一个长下坡接着一个 120 度转弯，大意了一点又看不到来车，然后就悲剧了，不过其实车速并不快，车虽然损伤不小但是人一点事没有，哈哈

你撞到大货车只是有凹陷有刮痕，那大货车估计毛事没有，你想多了，其实这点小事真和你最初想的一样，还车时和他们说一声就行了，如果买了尊享的话你啥事都不用管了，神舟处理这种事情流程还是可以的，租过神舟不少次，还出过大事故正面撞，发动机都废了，驾驶位轮子都快撞飞了，给他们打了电话很快就来拖车托走了，后面也只是需要交维修押金，保险维修啥都不需要管，虽然维修花了不少时间，但是维修押金也正常退回来了，后面爆胎啥的也出过，刮蹭就好多次了，其实也没啥，别太担心了，哈哈

源地址变换，自然是源地址映射，你这源地址和目的地址映射看起来当然不对，不同源地址端口映射到公网之后 ip 相同但是端口不同啊，相应的时候目的地址端口就是映射的公网地址端口，一查就知道对应的是哪个内网地址端口了

@caicaiwoshishui #49 call_soon_threadsafe 就可以在另外一个线程给 asynico 添加一个 callback 了，django 需要等等 callback 结果那就是多线程编程 Lock 、Event 、Semaphore 的东西了，写了个 flask 简单示例可以看看

https://gist.github.com/snower/b6d0288c60f4d40e544fb530a011ce62

java 感觉逻辑就是，分层、结构、解耦、扩展好维护，要考虑流量上来了团队壮大了如何如何，结果现实情况加班加点做完每三个月项目黄了，其实光是上半年就倒闭了数十万家公司，能做起来的少之又少，想这么多都是有的没的，特别是 mybatis 这一套，小公司使用场景来看设计的简直神经病一样的，所以依据自己现实和工程方法，选择合适的方案就可以了，没必要硬套这些东西

@caicaiwoshishui #45 asynico 的 ioloop 就是个 while True 死循环，所以如果你 django 运行在主线程，那么 asynico 就需要单独创建线程来运行了啊，而 asynico 的默认 get_event_loop 获取的是绑定到当前线程的，否则你就需要用个全局变量啥的保存这生成的 loop，这样就可以操作另外线程的 loop 了，再者 django 这种 web 程序又不是桌面 gui 程序，主线程哪里来的事件循环，asynico 似乎没有获取主线程事件循环的问题吧

@sujin190 #43 好吧，纠正一下，asyncio 也是每次 coroutine 每次迭代之后如果没用遇到 io 操作啥的需要等待就重新加入调度器队列，否则就在 io 完成后再重新加入调度器队列，这样调度器就可以在多个协程中相互切换了，并没用直接切换栈帧，那么确实不算是完全耦合在一起，其实似乎还是直接切换栈帧来的效率更高吧

@frostming #41 我看了下 trio 的实现，原理是调度器每 coroutine 迭代一步都需要重新压入调度器队列才能进行下一步，如果需要等待 io 就别压入调度器队列，这样调度器就可以切换到其它协程了，好吧，这也是一个方法，不过说起来 tornado 在 python2 上的实现其实也是这样的

但似乎 asyncio 的做法是直接切换栈帧的，对 coroutine 的每步迭代也是 c 直接写的，这两者效率差距有点大啊，asyncio 的 future 对象也是直接 c 写的

@frostming #41 这个的主要问题是，无论你用 async 方法 await 调用多少层，最终肯定会落到一个不是 async 或者 c 扩展的方法去，而这个方法是不能 await 的，如果你还需要等等 io 完成无法立刻得到结果，此时就需要有方法可以切换到其它协程去，而这个过程解释器层和 asyncio 耦合在一起了，还有 future 对象，set_result 后并没有直接触发 await，而是又走了一次 ioloop 循环，这个也直接写了就是走 asyncio

@ysc3839 #37 静态语言改编译器，改内存布局能，直接长 jmp 就是牛逼，这是在编译时直接把 test 函数拆成几个了啊

@ysc3839 #36 https://gist.github.com/snower/c4f1d4d55281e9456daf1a66831db821

async 函数调用后其实返回了一个 coroutine 对象，python 默认不会启动调度器，所以默认并不会运行这个 coroutine 对象，JavaScript 可以，那是因为 JavaScript 默认就启动了调度器，全局定义为被执行的 Promise 都会默认被直接执行，这两个没啥区别

当然 python async 函数调用返回 coroutine 使用 send 函数就能手动运行起来了，但是注意 asyncio 的 Future 调用 set_result 触发 await 返回其实是又被放到当前 asyncio loop 中去执行了，所以你还是要用 asyncio 创建 loop 来运行

我看 c++ 20 的协程也是需要调度器的吧

@kaishui00 #6 抓包发的内容格式也一样么？一样的话不应该啊，注意请求头也要设置完整啊，比如要正确设置 content-length，还有这个 Content-CRC32，如果服务器有 crc32 校验的话，不设置也会失败的吧，其它自定义的还有 X-Storage-U 不知道干啥的，Authorization 也要设置正确的登录校验信息

猜测整个请求体就是这个文件内容吧，没有任何编码，然后要在 Content-Length 指明文件长度

@ysc3839 #33 你这是把 c++和 JavaScript es5 的实现想完全搬到 python 上来啊，但事实上这两都是没有更好方法的时候不得已才这样用的，python 的实现更简单，用 future 对象把那些用 callback 的库包装一下就行了

```
def func(callback):
callback()

def func_await():
futuer = Futuer()
def on_finish():
futuer.set_result()
a(on_finish)
return futuer

async def test():
func1()
await func_await()
await func_await2()
func2()
```

大概就是这样样子就好了

@ysc3839 #30 关于 C++协程据我之前看过几个库的实现来看，c++作为底层语言，自身就能够通过操作内存结构和长 jmp 指令改变调用栈，所以基于此是可以无需调度器就可以完成协程切换的，但是无论 Javascript 、python 、ruby 、php 这样的语言可是都做不到手动修改栈帧这样的操作，这点和 c++这样的更底层的语言还是很大不同的，Javascript 看起来有点像，也只是解释器会隐式加很多东西

@ysc3839 #30 我知道你说的是啥，其实就是 future 对象吧，需要传 callback 的地方你可以构造一个 future 对象传过去，future 的 set_result 就是你说的 c++中的那个能拿到协程的“回调函数”了，Javascript 的异步函数返回时一个 Promise 对象，换言之，你需要传 callback 也可以改成传 Promise 对象，Javascript 不需要显示把协程放在调度器中运行时因为自动在全局包了一个调度器函数，其实底层和 python 是一样的

@ysc3839 #28 JavaScript 语言直接自带调度器，你都不能不要，不知道你用的 C++的库是啥，其实你这个想法才挺奇怪，async await 语法本来就是 A 等待 B 的一个结果，本身就代表有两个独立调用栈，没用调度器，直接一个单一线程如何能驱动两个独立调用栈运行呢