recv通信为啥无法在recv_stream执行？

recv通信为啥无法在recv_stream执行？

在 recv_stream 会hang. 在计算流可以正确执行、不会hang，且因为需要recv完成后才能后续计算，所有对性能应该无影响

这个函数特别长（300+行代码），有许多if-else判断，但其核心流程都是相似的：在一个有序的program序列中（fwd -> recv_fwd -> fwd -> bwd -> send_bwd -> opt），指定将某个op保留在其中某个program，在其它program中将该op删除，同时为后继的program建立新的数据依赖关系。
这个操作可否抽象成可复用的公共函数，以降低后续理解和维护代码的成本？

这个函数特别长（300+行代码），有许多if-else判断，但其核心流程都是相似的：在一个有序的program序列中（fwd -> recv_fwd -> fwd -> bwd -> send_bwd -> opt），指定将某个op保留在其中某个program，在其它program中将该op删除，同时为后继的program建立新的数据依赖关系。 这个操作可否抽象成可复用的公共函数，以降低后续理解和维护代码的成本？

Thx,这里我抽象出来，以提高可读性降低维护成本。

为何需要从外部传入type_to_skip_gc_vars，有一些数据依赖关系信息不包含在sub_programs的表达中吗？

为何需要从外部传入type_to_skip_gc_vars，有一些数据依赖关系信息不包含在sub_programs的表达中吗？

这里主要是处理这种场景：recv_fwd 中 send 的变量，被 fwd 和 bwd 同时使用，但 fwd 阶段不能gc。sub_programs 可以表达，但需要“重复”分析依赖关系，而依赖关系在1f1b split program 时分析过且代码较复杂，为避免重复，这里直接外部传入了。

fixed
#70615

这个开关是否直接去除或默认打开？如果保留的话建议换个名字，FLAGS_enable_p2p_comm_opt从名字无法方便地知道底层具体做的是什么通信优化（实际并不是通信优化，只是改变了编排方式，也不会提升性能）。

这个开关是否直接去除或默认打开？如果保留的话建议换个名字，FLAGS_enable_p2p_comm_opt从名字无法方便地知道底层具体做的是什么通信优化（实际并不是通信优化，只是改变了编排方式，也不会提升性能）。

Thx, 可以。已线下沟通确认，将默认打开。