各位朋友大家好，我是不会写代码的纯序员——Chunel，很高兴又和大家见面了。往前一算，有两个月没有更新博客了。这算不算是一种超时呢？——这一句话，引出了后面的全文，嘿嘿。
在开发的过程中，我们经常会遇到一些奇奇怪怪的问题，导致异常一步一步的堆积。我举个例子，比如：在一个链路中，先请求远端的 server，然后拿到结果后，简单处理一下，最后在控制台上打印结果。
就这么简单的一个流程，也可能会出现很多意想不到的坑。就比如，如果server中，不小心走到了一个sleep 1000s的逻辑，那pipeline的第一个node，就很长时间都走不完了对吧。后面的逻辑，就在那里干等着了。或者说server内部实际上已经执行出错了，我们还不知道捏。
为了解决类似的这种问题，我们花了一些时间，最终在色丶图的执行逻辑中，加入了超时机制。接下来，就跟大家介绍一下相关的内容。
按照惯例，首先上源码：
| 超时设置 |
pipeline流程中，有些逻辑涉及到数据库、三方服务等，不可避免的会遇到执行时间不确定的情况。在这个情况下，我们可以通过 setTimeout 接口，来设置当前 node的最大执行时间。
enum class GElementTimeoutStrategy {
AS_ERROR = 1, // 当做异常处理（默认）
HOLD_BY_PIPELINE = 2, // pipeline run执行完成之前，等待结束
NO_HOLD = 3, // 不等待结束。非特殊场景，强烈不推荐使用，不排除个别平台会出现崩溃的情况
};
GElement* setTimeout(CMSec timeout, GElementTimeoutStrategy strategy)
我们来看一下这个接口哈。第一个参数超时时长，单位是ms，代表当前node执行超过这个时间之后，就会结束执行。
第二个参数是超时的处理策略。默认情况下，执行超时就直接返回错误，pipeline也就随之结束了。这个是默认的策略。
第二种呢，也是比较推荐的处理策略，就是超时了也不退出，而是继续走接下来的流程。不过呢，会在pipeline整体执行结束之前，统一等待这些超时逻辑执行完毕——这样做是因为 node中可能会对全局的GParam参数进行写入或读取，pipeline开始和结束的瞬间，也会对GParam进行处理。框架层面必须避免这个之间带来的影响。
第三种捏，也就是 NO_HOLD，就是pipeline结束之前不做回收，强烈不推荐。原因就是可能出现上面提到的影响——除非你确定这样做，对你的整体流程，没有任何影响。
具体使用代码，可以参考这个demo：CGraph timeout tutorial
| 超时判断 |
前面我们提到过一个问题，就是当前的element执行超时了之后，如果不当做错误返回，后面的逻辑就会继续执行。
考虑这样一种情况：一个node，执行的真实时长是5s，但是超时时间设置为1s。那么，在如果它在第4s的时候，将pipeline中的一个 GParam的参数的值做了修改，那后面（第4s后）执行的node中，获取的 GParam的值是修改后的值么？
答案是：是的。因为在CGraph中，全局共享一处GParamManager管理类，在其中的任何改动，都是全局可见的。而且这种改动，有时候的确是必要的，或者说是符合开发者预期的。
但是，如果你想确保，当前node在超时后，就无法再修改GParam，那就需要在修改前，做一个判断：isTimeout()。如果返回值为true的话，那表明当前已经处于超时状态了。
还有一点需要说明的是，如果当前执行的group超时，或者这group中的所有正在执行的node，和未执行的node，都被认定为超时。
| 相关逻辑 |
围绕着超时机制展开的，还有一些其他的逻辑。比如，您可以在某个特定阶段，通过 GFence 等待你指定的前面的某几个超时节点执行完成。也可以通过GSome 来实现类似弱依赖的功能。相关的视频，我们已经放到B站上，欢迎观看：
| 本章小结 |
CGraph从开始到现在，已经经历了近一坤年。最近，在v2.5.0之后，我们在有超时逻辑的异步执行上，做了很多事情，弥补了在并行执行逻辑中的重要一环。相信这些改变，也会帮助大家更好的去完成自己的dag逻辑。
我们博客也维护很长时间了，这些日子，项目的结构和设计发生了很多变化，我们也没有来及去讲原先文章里的介绍做调整。有些新朋友，看到最早的博客，对照当前的代码，跟我们反馈，说是已经面目全非了——当然，一段时间后，这一篇文章也会面目全非，哈哈。在这里，我们表示抱歉。
其实，CGraph的设计思路挺简单的，代码行文也是高度统一的，相信你看完其中一个部分，就可以触类旁通的了解其他的内容。后期，我们会尽可能通过视频的方式，跟大家讲清楚CGraph的内部设计原理。
也欢迎对这些内容感兴趣的朋友，添加我的个人微信，随时交流指教。如果能pr一些内容，或是提出一些不足，那可就更好了。
[2023.10.04 by Chunel]
推荐阅读
- 纯序员给你介绍图化框架的简单实现——执行逻辑
- 纯序员给你介绍图化框架的简单实现——循环逻辑
- 纯序员给你介绍图化框架的简单实现——参数传递
- 纯序员给你介绍图化框架的简单实现——条件判断
- 纯序员给你介绍图化框架的简单实现——面向切面
- 纯序员给你介绍图化框架的简单实现——函数注入
- 纯序员给你介绍图化框架的简单实现——消息机制
- 纯序员给你介绍图化框架的简单实现——事件触发
- 纯序员给你介绍图化框架的简单实现——线程池优化（一）
- 纯序员给你介绍图化框架的简单实现——线程池优化（二）
- 纯序员给你介绍图化框架的简单实现——线程池优化（三）
- 纯序员给你介绍图化框架的简单实现——线程池优化（四）
- 纯序员给你介绍图化框架的简单实现——线程池优化（五）
- 纯序员给你介绍图化框架的简单实现——线程池优化（六）
- 纯序员给你介绍图化框架的简单实现——性能优化（一）
- 纯序员给你介绍图化框架的简单实现——距离计算
- CGraph 主打歌——《听码农的话》
- 聊聊我写CGraph的这一年
- 从零开始主导一款收录于awesome-cpp的项目，是一种怎样的体验?
- 炸裂！CGraph性能全面超越taskflow之后，作者却说他更想…
- 以图优图：CGraph中计算dag最大并发度思路总结
- 【B站视频】CGraph 入门篇
- 【B站视频】CGraph 功能篇
- 【B站视频】CGraph 应用篇
个人信息
微信: ChunelFeng
邮箱: chunel@foxmail.com
个人网站：www.chunel.cn
github地址: https://github.com/ChunelFeng
