20210304关于析构的责任链规律 - ziyouzy/2021blog GitHub Wiki

责任链的任何一环无论因何种原因被析构后，接下来的都是出发析构链去析构他的下游其他river-node
而绝对不会去析构他的上有
来举几个例子：
1.usr-io808的net.Conn被析构后，由于他是这个riverConn的最初数据源(sources字段)，因此usr-io808整体就需要直接被析构了

2.如果是river-node中所设计的那个数据源模拟器，和他是一样的，因为析构时需要跳出如下循环：

go func(){
    for i:=0;i<=len(p.sourceTable);i++{
    if i == len(p.sourceTable){i = 0}
        p.config.News <- p.sourceTable[i]
        time.Sleep(p.config.StepSec)
    }
}()

而这一循环正式数据源，充当着sources的地位，于是步骤会变得和1一样，先跳出线程毁掉数据源，在关闭p.config.News管道激发下游的析构责任链

3.如果是未来的door模块，他大致的数据结构如下：

type Door struct{
    sources net.Conn //qtui的net.Conn
    Fin_Sender net.Conn //usr-io808的net.Conn
    ....
}

func(p *Door)Open(){
    if err :=p.net.Conn.Write("开门")； err !=nil{
        p.Errors<-err
    }
}

而当发现Fin_Sender net.Conn被析构了之后，Door不会调用任何显式析构操作，如果又发生了需要执行Open的操作也会自动调用Open()方法，但是也会把开门失败的结果返回给上级(p.Errors<-err)

最主要的还是在于，某个river-node的析构只会去向下进行链式触发，而绝对不会向上
另外就是对于qtui与usr-io808的对接操作该是什么逻辑呢？