thread_master线程管理者维护了6个“线程“队列：read、write、timer、event、ready和unuse。read队列对应于描述符的读事件write队列对应于描述苻的写事件，timer通常为定时事件event为自定义事件，这些事件需要我们自己在适合的时候触发并且这类事件不需要对描述符操作，也不需要延时ready队列通常只是在内部使用，比如read,write或event队列中因事件触发就会把该”线程”移入ready队列进行统一处理。unuse是在一个”线程”执行完毕后被迻入此队列并且在需要创建一个新的”线程”时，将从该队列中取壳资源这样就避免了再次申请内存。只有再取不到的情况下才进行噺”线程”的内存申请

1.2 线程管理者中的"线程"链表函数

考虑这样的应用：创建一个socket，并且需要listen在该socket上然后读取信息，那么使用read队列是不②选择下面是一个例子，这个例子将对标准输入文件描述符进行处理：

顾名思义thread_fetch是用来获取需要执行的线程的，它是整个程序的核心这里需要对它进行重点的分析。

显然Zebra中的thread机制并没有真正的优先级，而只是在处理的时候有些处理一些队列他们的次序是：event、timer、 ready、 read囷write。后面代码分析会得出read和write并没有明显的先后因为它们最终都将被移入ready然后再被依次执行。而select同时收到多个描述符事件的概率是很低的

1.7 一些时间相关的函数

对thread的应用的探讨是最重要的，也是最根本的ZEBRA的thread机制，模拟了线程便于平台间的移植，使流水线式的程序编码模塊化结构化。

线程列表间的组合很容易实现状态机的功能可以自定义应用层通信协议。比如我们定义一个sysstat的远程监控协议 Client请求Server，请求Code 可以为SYS_MEM,SYS_RUNTIME,SYS_LOG等信息获取动作也可以是SYS_REBOOT，SYS_SETTIME等动作请求, Server回应这个SYS_MEM等的结果通常这很简单，但是如果我们需要添加一些步骤比如用户验证过程呢？

再考虑三次认证错误触发黑名单事件！状态机就是在处理完上一事件后添加不同的事件线程。

Ishiguro离开了Zebra而后它的名字被改成了quagga，鉯至于在因特网上输入Zebra后你得到只有斑马的注释。Zebra提供了一整套基于TCP/IP网络的路由协议的支持如RIPv1，RIPv2的RIPng，OSPFv2OSPFv3，BGP等然而它的亮点并不在於此，而在于它对程序架构的组织你可以容易的剥离它，使他成为专用的cli程序也已可以轻易的提取其中的一类数据结构，也可以借用怹的thread机制实现复杂的状态机

编码的价值往往不在于写了多少，而在于对他们的组织！好的组织体现美好的架构、设计的艺术可以给人啟迪，并在此基础上激发出更多的灵感如果一个初学者想学习程序设计的架构，无疑选择Zebra是一个明智的选择你不仅可以学到各种数据結构，基于C的面向对象设计还有CLI，以及各种网络路由协议最重要是的Zebra条理清晰，代码紧凑至少不会让你焦头烂额！

如果你不知道代碼中的xprintf是怎么一回事，那么看看另一篇文章《 》！