在Python语言中Python线程可以从这里开始与主线程对GIL的竞争，在t_bootstrap中，申请完了GIL，也就是说子线程也就获得了GIL，使其始终保存着活动线程的状态对象。

当PyEval_AcquireThread结束之后，子线程也就获得了GIL，并且做好了一切执行的准备。接下来子线程通过PyEval_ CallObjectWithKeywords，将最终调用我们已经非常熟悉的PyEval_EvalFrameEx。

也就是Python的字节码执行引擎。传递进PyEval_CallObjectWithKeywords的boot->func是一PyFunctionObject对象，正是therad1.py中定义的threadProc编译后的结果。在PyEval_CallObjectWithKeywords结束之后，子线程将释放GIL，并完成销毁线程的所有扫尾工作，到了这里，子线程就结束了。

从t_bootstrap的代码看上去，似乎子线程会一直执行，直到子线程的所有计算都完成，才会通过PyThreadState_DeleteCurrent释放GIL。如此一来，那主线程岂非一直都会处于等待GIL的状态？如果真是这样，那Python线程显然就不可能支持多线程机制了。

实际上在PyEval_EvalFrameEx中，图15-2中显示的Python内部维护的那个模拟时钟中断会不断地激活线程的调度机制，在子线程和主线程之间不断地进行切换。从而真正实现多线程机制，当然，这一点我们将在后面详细剖析。现在我们感兴趣的是子线程在PyEval_AcquireThreade中到底做了什么。

到这里，了解了PyEval_AcquireThread，似乎创建线程的机制都清晰了。但实际上，有一个非常重要的机制——线程状态保护机制——隐藏在了一个毫不起眼的地方：

PyThreadState_New。
[threadmodule.c] static PyObject* thread_PyThread_start_new_thread(PyObject *self, PyObject *fargs) { PyObject *func, *args, *keyw = NULL; struct bootstate *boot; long ident; PyArg_UnpackTuple(fargs, "start_new_thread", 2, 3, &func, &args, &keyw); //[1]：创建bootstate结构 boot = PyMem_NEW(struct bootstate, 1); boot->interp = PyThreadState_GET()->interp; boot->funcfunc = func; boot->argsargs = args; boot->keywkeyw = keyw; //[2]：初始化多线程环境 PyEval_InitThreads(); /* Start the interpreter's thread-awareness */ //[3]：创建线程 ident = PyThread_start_new_thread(t_bootstrap, (void*) boot); return PyInt_FromLong(ident); [thread.c] /* Support for runtime thread stack size tuning. A value of 0 means using the platform's default stack size or the size specified by the THREAD_STACK_SIZE macro. */ static size_t _pythread_stacksize = 0; [thread_nt.h] long PyThread_start_new_thread(void (*func)(void *), void *arg) { unsigned long rv; callobj obj; obj.id = -1; /* guilty until proved innocent */ obj.func = func; obj.arg = arg; obj.done = CreateSemaphore(NULL, 0, 1, NULL); rv = _beginthread(bootstrap, _pythread_stacksize, &obj); /* use default stack size */ if (rv == (unsigned long)-1) { //创建raw thread失败 obj.id = -1; } else { WaitForSingleObject(obj.done, INFINITE); } CloseHandle((HANDLE)obj.done); return obj.id; }

这个机制对于理解Python线程的创建和维护是非常关键的。要剖析线程状态的保护机制，我们首先需要回顾一下线程状态。在Python中，每一个Python线程都会有一个线程状态对象与之关联。

在线程状态对象中，记录了每一个线程所独有的一些信息。实际上，在剖析Python的初始化过程时，我们曾经见过这个对象。每一个线程对应的线程状态对象都保存着这个线程当前的PyFrameObject对象，线程的id这样一些信息。有时候，线程是需要访问这些信息的。

比如考虑一个最简单的情形，在某种情况下，每个线程都需要访问线程状态对象中所保存的thread_id信息，显然，线程A获得的应该是A的thread_id，线程B亦然。倘若线程A获得的是B的thread_id，那就坏菜了。这就意味着Python线程内部必须有一套机制，这套机制与操作系统管理进程的机制非常类似。

我们知道，在操作系统从进程A切换到进程B时，首先会保存进程A的上下文环境，再进行切换；当从进程B切换回进程A时，又会恢复进程A的上下文环境，这样就保证了进程A始终是在属于自己的上下文环境中运行。

这里的线程状态对象就等同于进程的上下文，Python同样会有一套存储、恢复线程状态对象的机制。同时，在Python内部，维护着一个全局变量：PyThreadState * _PyThread- State_Current。

当前活动线程所对应的线程状态对象就保存在这个变量里，当Python调度线程时，会将被激活的线程所对应的线程状态对象赋给_PyThreadState_Current，使其始终保存着活动线程的状态对象。

这就引出了这样的一个问题：Python如何在调度进程时，获得被激活线程对应的状态对象？Python内部会通过一个单向链表来管理所有的Python线程的状态对象，当需要寻找一个线程对应的状态对象时。