Python 解释器是能够执行用其他计算机语言编写的程序的系统软件，它是一种翻译程序，相比之下，源代码解释器更易于创建，并且不需要一个独立的编译过程，这大大的增进了开发人员的兴趣。
到了这一步，子线程将自己挂起，操作系统的线程调度机制再也不能靠自身的力量将其唤醒，只有等待Python的线程调度机制强迫主线程放弃GIL后。子线程才会被唤醒；而子线程被唤醒之后，主线程却又陷入了苦苦地等待中，同样苦苦地守望着Python强迫子线程放弃GIL的那一刻。
当子线程被Python的线程调度机制唤醒之后，它所作的第一件事就是通过PyThreadState_Swap将Python维护的当前线程状态对象设置为其自身的状态对象，一如操作系统的进程上下文环境恢复一样。
现在我们的子线程开始等待GIL，但是注意，线程的初始化还没有真正完成，因为子线程还没有顺利进入字节码解释器。当Python线程调度将子线程唤醒之后。子线程将回到t_bootstrap中，并进入PyEval_CallObjectWithKeywords，从这里一直往前，最终将调用PyEval_EvalFrameEx，进入Python 解释器。到了那个时候，子线程和主线程一样，就完全被Python线程调度机制所控制了。
需要注意的是，PyThread_start_new_thread是在主线程中执行的，而从bootstrap开始，则是在子线程中执行的。其中涉及线程销毁的动作，如PyThreadState_ DeleteCurrent等，将在后续的部分剖析。
到了这里，读者可能有些疑惑了，我们花费了大量篇幅剖析的线程状态对象链表似乎没有什么用啊。其实不然，试想一下。
当线程调度发生时，在Python一级，需要通过之前剖析过的PyTrheadState_Swap函数切换当前的线程状态对象，这时候就需要根据线程id从线程状态对象链表中获取线程对象了。
事实上，在Python内部的许多API中，比如PyGILState_Ensure等等中，都会涉及这个链表，这些API在C与Python交互时可能被大量调用，有兴趣的读者可以自行深入探索一下。
Python 解释器包括两个主要的子系统：一个是表达式解析器，负责处理数字表达式；另一个是解释器，负责程序的实际执行。对于前者，可采用本书第2章所介绍的表达式解析器。但是在这里做了某些改进，使得解析器能够解析包含在程序语句中的数字表达式，而不是只能解析孤立的表达式。
解释器子系统和解析器子系统包含在同一个解释器类中，该类名为SBasic。尽管从理论上讲可以使用两个独立的类：一个包含Python 解释器，另一个包含表达式解析器；但是将两者用同一个类来实现的代效率会更高。
因为表达式解析器和Python 解释器的代码是密不可分的。例如，两个子系统都操作保存着程序代码的同一个字符数组。如果将它们分别安排在两个类中，将会增加可观的额外开销，并导致性能上的损失和功能上的重复。此外，由于程序解释的任务繁重，而解析表达式只是其中的一部分，因此将整个解释机制包含在单个类中是很有意义的。
Python 解释器执行时，每次从程序的源代码中读入一个标识符。如果读入的是关键字，解释器就按照该关键字的要求执行规定的操作。举例来说，当解释器读入一个PRINT后，它将打印PRINT之后的字符；当读入一个GOSUB时，它就执行指定的子程序。在到达程序的结尾之前，这个过程将反复进行。可以看到，解释器只是简单地执行程序指定的动作。
【编辑推荐】
