wandering-readily

谢谢兔兔，明白了很多概念~ 我在tcp 粘包的问题是这么做的： json.NewDecoder(conn).Decode(&opt) if err := json.NewEncoder(conn).Encode(opt); err != nil，json底层read可能过多取字节缓存，导致readRequestHeader()中cc.ReadHeader(&h)的"encoding/gob" decode(&h)时字节流可能缺少部分开头字节，我这里修改了往conn传入struct Option的方法，直接从conn输入取出option长度声明（option长度int32字段指定），这样完全取出option时不过多取出字节； 不过在DialHTTP中好像有个隐患，这我不太清楚， 1. NewHTTPClient() --> (1. HTTP CONNECT方法交流，而后传输option字节流) 2. Server的ServeHTTP(w http.ResponseWriter, req *http.Request)方法先确认CONNECT方法，而后Hijack()剥离conn，再调用ServeConn()方法，第一个步骤仍会是从conn中接受option的字节流 ##### 我的假设是net/http实现的交流会将tcp conn的所有字节取出，那么我下一次在已经建立的tcp conn连接上将会接收所有option字节（我不知道这个假设对不对，有没有后来者能解惑，谢谢了QAQ） #####...

> promise_type 的生命周期是运行时控制的，所以 sharedptr 不太行。其实矛盾点就是 Future 要等执行完才会析构，真实场景下还是自己做个线程池好了，别用 std::async 了。 我也是这么想的，实际任务应该开出几个固定线程给协程内容使用； 除了static变量和全局变量，有什么好办法能够在promise_type构造时就将线程池地址添加进去么，因为class Task需要尽量减少用户的手动操作，不能使用额外函数；线程池我需要它也能承担其它任务，例如IO； 额，我认为static变量和全局变量会影响代码可读性，也会带来模块共享的问题，即使加上namespace隔离 ~ (─‿─) 好像应该使用static变量和全局变量，这样就能保证线程池的生命周期和程序一样，不至于用户使用协程得到个非法的线程池地址