Python子线程在创建自身的线程状态对象后，会通过_PyGILState_NoteThreadState这个语句将这个对象放入到线程状态对象链表中，当前活动的Python子线程不一定是获得了GIL的线程。
在thread1.py中主线程现在是获得了GIL的，但是子线程到现在还没有申请GIL，自然也不会将自身挂起。由于主线程和子线程都是Win32的原生线程。所以操作系统可能在主线程和Python子线程之间切换。我们在这里要着重指出操作系统级的线程调度和Python级的线程调度是不同的。
Python级的线程调度一定意味着GIL拥有权的易手，而操作系统级的线程调度并不一定意味着GIL的易手，当所有的线程都完成了初始化动作之后。操作系统的线程调度和Python的线程调度才会同一。那时，Python的线程调度会迫使当前活动线程释放GIL，而这一操作会触发GIL中维护的Event内核对象。
这个触发又进而触发操作系统的线程调度。而在线程的初始化完成之前，在Python线程调度和操作系统线程调度之间并没有这样的因果关系。显示了GIL在Python级线程调度与操作系统级线程调度之间所起的桥梁作用。
前面我们已经剖析过PyEval_AcquireThread的代码，在PyEval_AcquireThread中，子线程进行了***的冲刺，它要生存，要执行，于是它开始通过PyThread_acquire_ lock争取GIL。到了这一步。
Python子线程将自己挂起，操作系统的线程调度机制再也不能靠自身的力量将其唤醒，只有等待Python的线程调度机制强迫主线程放弃GIL后。子线程才会被唤醒；而子线程被唤醒之后，主线程却又陷入了苦苦地等待中，同样苦苦地守望着Python强迫子线程放弃GIL的那一刻。
当子线程被Python的线程调度机制唤醒之后，它所作的***件事就是通过PyThreadState_Swap将Python维护的当前线程状态对象设置为其自身的状态对象，一如操作系统的进程上下文环境恢复一样。
现在我们的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交互时可能被大量调用，有兴趣的读者可以自行深入探索一下。
【编辑推荐】
