对于Bitabase这个项目，我并没有计划把它做得很复杂。首先分为两个大模块：Bitabase部分承担真正的爬取工作部分，web（还没有想好名字）会渲染一个简单的本地网站用于把数据展示出来，以及提供操作接口以控制爬虫的工作。虽然项目迁移到了macOS/PyCharm的开发环境，但是依然保留着Visual Studio的结构，因为……懒。开玩笑啦，要不是VS的补全实在太慢，也许到现在这还是一个Windows底下开发的项目。
Bitabase底下没有更加细分的模块。interface.py是面向标准库和第三方库的一个封装，理论上其上方的代码就不用再直接引用任何其他库了，全部需求可以由它本身满足；base.py是代码真正的基础，将interface.py里提供的原始的、面向过程的接口改造成为需求量身定制的形状，所有应用层的代码（比如web模块）都不应该越过base而直接引用interface。今天要讲的就是base模块当中最开始的一部分。
写完标题发现又是一篇《简单xxx》的文章。写个啥都是简单版，我好菜啊。
这篇文章涉及到的线程模型主要的使用场景是爬虫线程。作为一个高大上的爬虫，有一个问题一定要处理好的：突然断网怎么办。这也许就是一个每天晚上宿舍熄灯的人说不出的痛。我倒不是很在乎速度，使用阻塞式的网络请求也没关系；也不太在意CPU利用率，所以哪怕是主线程等待我也不着急。但问题就是我希望我的爬虫是“可暂停”的：不仅仅可以冻结当前状态，而且还能把部分成果拿出来。因此，一个单工作线程的“线程池”模型横空出世。【虽然后来也不是线程池了
使用单线程工作的好处是省了很多锁，而且并没有损失拓展性：反正以后要是等不及了再在这个线程底下开线程池也没关系是不是。
我也不记得这是我第几次口口声声说着“我再也不用C++了”然后又用了C++。用了会浪费大量时间，使程序陷入无限复杂度；不用会浪费大量代码量，使程序陷入无限繁琐。一个小循环过后就会进入大循环的下一个步骤：开始转向Python等快速迭代的脚本语言，直到忍受不了其灵活而转回所谓“一步一个脚印”的主导思想当中来。唉，如果上天再给我一次机会，我坚决不学C以外的其他语言。最多加上Python。好吧还是得有Java或者C#。算了当我什么都没说。
这次实现的图是在昨天写完C版本的图之后，实在没忍住的成果。不知道为什么，在自己写的数据结构之上工作总有一种上不了台面的感觉，没有用STL来的舒坦。强烈克制住删代码的冲动以后，写了一套完全平行的图（项目代码膨胀的一个活生生的例子），并且放弃了“底层用STL上层暴露为C接口”的想法，毕竟用了C++而不用C++11，或者用了C++11而不用匿名函数，那么和咸鱼也没有什么区别了。
其实这是一种“假”的数据结构，没有什么新的结构，甚至平行数组都没有，它就是一个简单的……数组
|
|
一切操作，都围绕着这个如假包换的数组展开。
