程序员闪电侠

带着镜像基础信息准备好后，又将要用来做什么的问题。 袁小白重新回到edge.go的unpark函数里，看到了接下来的动作： 顺着代码就找到了接下来需要发生的操作：e.execReq...

在SourceOp的CacheMap里，需要获取s.instance，而这里又依赖于s.sm.Resolve，可以看到sm实际上就是source.Manager，依赖于Resolve方法...

要想理解递归，除了抽象出同样的行为外，再就是找到循环的出口。 在上一次梳理的结果中可以看到，Edge1是递归的最后一个edge，在edge中，由于SourceOp的inputs为空...

scheduler.build 现在有两个Edge，Scheduler会怎么编排任务呢？ Scheduler开始构建的地方： 可以看到，最先获取edge，然后创建EdgePipe来处理Edge...

为了理解龙飞讲解的scheduler，袁小白先是去了解了pipe的使用方法和设计原理，现在回忆起来，有以下特点： pipe由sender和receiver组成...

袁小白也看过类似的设计模式，如pipe。 大体的思路就是抽象出运行操作的环境，有输入，有输出。 将操作的执行有序的衔接起来。 如果想要做得灵活一点，输入和输出可以不用统一，甚至可以自定义...

龙飞介绍完scheduler后，袁小白感觉是懂非懂。 说懂呢，因为大概了解到scheduler是如何将edge进行构建的，是如何拆解的，等等。 但要说到底是如何工作的，却又理不清，道不明...

果然不出袁小白所料，这scheduler还真不简单 - 因为没看懂，自己琢磨了一个星期，愣是没弄明白调度器是scheduler是怎么调度的。 没耐住性子，又求助了龙飞。 龙飞一如既往的没有让袁小白失望

从龙飞给出的buildctl build全景时序图中可以了解到： Worker是用来真正运行容器的，那jobs的定位又是什么呢？