', {
+ 'href': gitbook.state.basePath + '/' + item.url + '?h=' + encodeURIComponent(res.query),
+ 'text': item.title,
+ 'data-is-search': 1
+ });
+
+ if ($link[0].href.split('?')[0] === location.href.split('?')[0]) {
+ $link[0].setAttribute('data-need-reload', 1);
+ }
+
+ var content = item.body.trim();
+ if (content.length > MAX_DESCRIPTION_SIZE) {
+ content = content + '...';
+ }
+ var $content = $('').html(content);
+
+ $link.appendTo($title);
+ $title.appendTo($li);
+ $content.appendTo($li);
+ $li.appendTo($searchList);
+ });
+ $('.body-inner').scrollTop(0);
+ }
+
+ function escapeRegExp(keyword) {
+ //escape regexp prevserve word
+ return String(keyword).replace(/([-.*+?^${}()|[\]\/\\])/g, '\\$1');
+ }
+
+ function query(keyword) {
+ if (keyword == null || keyword.trim() === '') return;
+
+ var results = [],
+ index = -1;
+ for (var page in INDEX_DATA) {
+ if ((index = INDEX_DATA[page].body.toLowerCase().indexOf(keyword.toLowerCase())) !== -1) {
+ results.push({
+ url: page,
+ title: INDEX_DATA[page].title,
+ body: INDEX_DATA[page].body.substr(Math.max(0, index - 50), MAX_DESCRIPTION_SIZE)
+ .replace(/^[^\s,.]+./,'').replace(/(..*)[\s,.].*/, '$1') //prevent break word
+ .replace(new RegExp('(' + escapeRegExp(keyword) + ')', 'gi'), '$1')
+ });
+ }
+ }
+ displayResults({
+ count: results.length,
+ query: keyword,
+ results: results
+ });
+ }
+
+ function launchSearch(keyword) {
+ // Add class for loading
+ $body.addClass('with-search');
+ $body.addClass('search-loading');
+
+ function doSearch() {
+ query(keyword);
+ $body.removeClass('search-loading');
+ }
+
+ throttle(doSearch)();
+ }
+
+ function closeSearch() {
+ $body.removeClass('with-search');
+ $('#book-search-results').removeClass('open');
+ }
+
+ function bindSearch() {
+ // Bind DOM
+ var $body = $('body');
+
+ // Launch query based on input content
+ function handleUpdate() {
+ var $searchInput = $('#book-search-input input');
+ var keyword = $searchInput.val();
+
+ if (keyword.length == 0) {
+ closeSearch();
+ } else {
+ launchSearch(keyword);
+ }
+ }
+
+ $body.on('keyup', '#book-search-input input', function(e) {
+ if (e.keyCode === 13) {
+ if (usePushState) {
+ var uri = updateQueryString('q', $(this).val());
+ history.pushState({
+ path: uri
+ }, null, uri);
+ }
+ }
+ handleUpdate();
+ });
+
+ // Push to history on blur
+ $body.on('blur', '#book-search-input input', function(e) {
+ // Update history state
+ if (usePushState) {
+ var uri = updateQueryString('q', $(this).val());
+ history.pushState({
+ path: uri
+ }, null, uri);
+ }
+ });
+ }
+
+ gitbook.events.on('start', function() {
+ bindSearch();
+ $.getJSON(state.basePath + "/search_plus_index.json").then(function(data) {
+ INDEX_DATA = data;
+ showResult();
+ closeSearch();
+ });
+ });
+
+ // 高亮文本
+ var highLightPageInner = function(keyword) {
+ $('.page-inner').mark(keyword, {
+ 'ignoreJoiners': true,
+ 'acrossElements': true,
+ 'separateWordSearch': false
+ });
+
+ setTimeout(function() {
+ var mark = $('mark[data-markjs="true"]');
+ if (mark.length) {
+ mark[0].scrollIntoView();
+ }
+ }, 100);
+ };
+
+ function showResult() {
+ var keyword, type;
+ if (/\b(q|h)=([^&]+)/.test(location.search)) {
+ type = RegExp.$1;
+ keyword = decodeURIComponent(RegExp.$2);
+ if (type === 'q') {
+ launchSearch(keyword);
+ } else {
+ highLightPageInner(keyword);
+ }
+ $('#book-search-input input').val(keyword);
+ }
+ }
+
+ gitbook.events.on('page.change', showResult);
+
+ function getParameterByName(name) {
+ var url = window.location.href;
+ name = name.replace(/[\[\]]/g, '\\$&');
+ var regex = new RegExp('[?&]' + name + '(=([^&#]*)|&|#|$)', 'i'),
+ results = regex.exec(url);
+ if (!results) return null;
+ if (!results[2]) return '';
+ return decodeURIComponent(results[2].replace(/\+/g, ' '));
+ }
+
+ function updateQueryString(key, value) {
+ value = encodeURIComponent(value);
+
+ var url = window.location.href.replace(/([?&])(?:q|h)=([^&]+)(&|$)/, function(all, pre, value, end) {
+ if (end === '&') {
+ return pre;
+ }
+ return '';
+ });
+ var re = new RegExp('([?&])' + key + '=.*?(&|#|$)(.*)', 'gi'),
+ hash;
+
+ if (re.test(url)) {
+ if (typeof value !== 'undefined' && value !== null)
+ return url.replace(re, '$1' + key + '=' + value + '$2$3');
+ else {
+ hash = url.split('#');
+ url = hash[0].replace(re, '$1$3').replace(/(&|\?)$/, '');
+ if (typeof hash[1] !== 'undefined' && hash[1] !== null)
+ url += '#' + hash[1];
+ return url;
+ }
+ } else {
+ if (typeof value !== 'undefined' && value !== null) {
+ var separator = url.indexOf('?') !== -1 ? '&' : '?';
+ hash = url.split('#');
+ url = hash[0] + separator + key + '=' + value;
+ if (typeof hash[1] !== 'undefined' && hash[1] !== null)
+ url += '#' + hash[1];
+ return url;
+ } else
+ return url;
+ }
+ }
+ window.addEventListener('click', function(e) {
+ if (e.target.tagName === 'A' && e.target.getAttribute('data-need-reload')) {
+ setTimeout(function() {
+ location.reload();
+ }, 100);
+ }
+ }, true);
+});
\ No newline at end of file
diff --git a/gitbook/gitbook-plugin-sharing-plus/buttons.js b/gitbook/gitbook-plugin-sharing-plus/buttons.js
new file mode 100644
index 0000000..d63e0f9
--- /dev/null
+++ b/gitbook/gitbook-plugin-sharing-plus/buttons.js
@@ -0,0 +1,71 @@
+require(['gitbook', 'jquery'], function(gitbook, $) {
+ function site(label, icon, link) {
+ return {
+ label: label,
+ icon: 'fa fa-' + icon,
+ onClick: function (e) {
+ e.preventDefault();
+ window.open(link);
+ }
+ };
+ }
+
+ var url = encodeURIComponent(location.href);
+ var title = encodeURIComponent(document.title);
+
+ var SITES = {
+ douban: site('豆瓣', 'share', 'http://shuo.douban.com/!service/share?href=' + url + '&name=' + title),
+ facebook: site('Facebook', 'facebook', 'http://www.facebook.com/sharer/sharer.php?s=100&p[url]=' + url),
+ google: site('Google+', 'google-plus', 'https://plus.google.com/share?url=' + url),
+ hatenaBookmark: site('はてなブックマーク', 'bold', 'http://b.hatena.ne.jp/entry/' + url),
+ instapaper: site('instapaper', 'instapaper', 'http://www.instapaper.com/text?u=' + url),
+ line: site('LINE', 'comment', 'http://line.me/R/msg/text/?' + title + ' ' + url),
+ linkedin: site('Linkedin', 'linkedin', 'https://www.linkedin.com/shareArticle?mini=true&url=' + url),
+ messenger: site('Facebook Messenger', 'commenting', 'fb-messenger://share?link=' + url),
+ pocket: site('Pocket', 'get-pocket', 'https://getpocket.com/save?url=' + url + '&title=' + title),
+ qq: site('QQ', 'qq', 'http://connect.qq.com/widget/shareqq/index.html?url=' + url + '&title=' + title),
+ qzone: site('QQ空间', 'star', 'http://sns.qzone.qq.com/cgi-bin/qzshare/cgi_qzshare_onekey?url=' + url + '&title=' + title),
+ stumbleupon: site('StumbleUpon', 'stumbleupon', 'http://www.stumbleupon.com/submit?url=' + url + '&title=' + title),
+ twitter: site('Twitter', 'twitter', 'https://twitter.com/intent/tweet?url=' + title + '&text=' + title),
+ viber: site('Viber', 'volume-control-phone', 'viber://forward?text='+ url + ' ' + title),
+ vk: site('VK', 'vk', 'http://vkontakte.ru/share.php?url=' + url),
+ weibo: site('新浪微博', 'weibo', 'http://service.weibo.com/share/share.php?content=utf-8&url=' + url + '&title=' + title),
+ whatsapp: site('WhatsApp', 'whatsapp', 'whatsapp://send?text='+ url + ' ' + title),
+ };
+
+ gitbook.events.bind('start', function(e, config) {
+ var opts = config.sharing;
+
+ // Create dropdown menu
+ var menu = $.map(opts.all, function(id) {
+ var site = SITES[id];
+
+ return {
+ text: site.label,
+ onClick: site.onClick
+ };
+ });
+
+ // Create main button with dropdown
+ if (menu.length > 0) {
+ gitbook.toolbar.createButton({
+ icon: 'fa fa-share-alt',
+ label: 'Share',
+ position: 'right',
+ dropdown: [menu]
+ });
+ }
+
+ // Direct actions to share
+ $.each(SITES, function(sideId, site) {
+ if (!opts[sideId]) return;
+
+ gitbook.toolbar.createButton({
+ icon: site.icon,
+ label: site.text,
+ position: 'right',
+ onClick: site.onClick
+ });
+ });
+ });
+});
diff --git a/gitbook/gitbook-plugin-splitter/splitter.css b/gitbook/gitbook-plugin-splitter/splitter.css
new file mode 100644
index 0000000..4e84720
--- /dev/null
+++ b/gitbook/gitbook-plugin-splitter/splitter.css
@@ -0,0 +1,22 @@
+.divider-content-summary {
+ position: absolute;
+ top: 0;
+ right: 0;
+ height: 100%;
+ width: 5px;
+ display: table;
+ cursor: col-resize;
+ color: #ccc;
+ -webkit-transition: color 350ms ease;
+ -moz-transition: color 350ms ease;
+ -o-transition: color 350ms ease;
+ transition: color 350ms ease
+}
+.divider-content-summary:hover {
+ color: #444;
+}
+ .divider-content-summary__icon {
+ display: table-cell;
+ vertical-align: middle;
+ text-align: center;
+ }
diff --git a/gitbook/gitbook-plugin-splitter/splitter.js b/gitbook/gitbook-plugin-splitter/splitter.js
new file mode 100644
index 0000000..5034e5b
--- /dev/null
+++ b/gitbook/gitbook-plugin-splitter/splitter.js
@@ -0,0 +1,128 @@
+require(['gitbook', 'jQuery'], function (gitbook, $) {
+
+ // MEMO:
+ // Gitbook is calculated as "calc (100% - 60px)" in the horizontal width when the width of the screen size is 600px
+ // or less.
+ // In this case, since contradiction occurs in the implementation of this module, return.
+ if($(window).width() <= 600) {
+ return;
+ }
+
+ gitbook.events.bind('start', function () {
+ });
+
+ gitbook.events.bind('page.change', function () {
+
+ var KEY_SPLIT_STATE = 'plugin_gitbook_split';
+
+ var dividerWidth = null;
+ var isDraggable = false;
+ var dividerCenterOffsetLeft = null;
+ var splitState = null;
+ var grabPointWidth = null;
+
+ var $body = $('body');
+ var $book = $('.book');
+ var $summary = $('.book-summary');
+ var $bookBody = $('.book-body');
+ var $divider = $('
' +
+ '
' +
+ '' +
+ '
' +
+ '
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ 介绍
+本项目致力于对 Python 3.7 的源码分析，深度参考陈儒大大的《Python 源码剖析》，编写 Python 3 的版本。
+希望各位 Python 爱好者能参与其中，一起探索 Python 魔法背后的奥秘！
+使用
+您可以直接访问 在线版，或者根据以下步骤访问本地版。
+前置条件
+您的系统上需要安装好 node （会自带npm）。
+使用 make 或者使用 npm 命令去构建
+使用 make 命令的方式构建：
+若您可使用 make 命令，简单执行如下命令进行初始化：
+make init
+
+执行如下命令运行服务端：
+make run
+
+使用 npm 命令的方式构建：
+若您不能使用 make 命令，或想直接使用 npm 命令，执行如下命令进行初始化：
+安装项目依赖：
+npm install
+
+执行如下命令运行服务端：
+npm run serve
+
+访问
+直接访问 http://localhost:4000 即可查看本书内容。
+Roadmap
+大体按照《Python 源码剖析》中的目录结构进行编写。依次介绍 Python 源码基本信息、内建对象和虚拟机。
+
+- [x] 章节
+- [x] 序章
+- [x] 前言
+- [x] Python 源代码的组织
+- [x] Windows 环境下编译 Python
+- [x] UNIX/Linux 环境下编译 Python
+- [x] 修改 Python 源码
+
+
+- [ ] Python 内建对象
+- [x] Python 对象初探
+- [x] Python 整数对象
+- [ ] Python 字符串 对象
+- [x] Python List 对象
+- [x] Python Dict 对象
+- [x] Python Set 对象
+- [ ] 实现简版 Python
+
+
+- [ ] Python 虚拟机
+- [ ] Python 编译结果
+- [ ] Python 虚拟机框架
+- [ ] 虚拟机一般表达式
+- [ ] Python 虚拟机控制流
+- [ ] Python 虚拟机函数机制
+- [ ] Python 运行环境初始化
+- [ ] Python 模块加载机制
+- [ ] Python 多线程机制
+- [ ] Python 内存管理机制
+
+
+
+
+
+
+
+
+
+
+
+
results matching ""
+
+
+
+
+
+
No results matching ""
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
-
-由于我们只是研究 Python 的核心部分，可以选择不编译标准库和外部依赖，在“配置属性”->“配置”中仅勾选
-python 和 pythoncore，然后点击“确定”（如下图所示）。
-
-此外，默认情况下的编译设置是 Debug、32 位，您也可以根据自己的需求调整成 Release 或 64 位。
-
-
-
-在左侧的解决方案目录中选择 python，右键选择“生成”，以进行编译：
-
-
-
-编译结束后，生成的文件存放在`PCbuild\win32`目录下（如下图所示），打开`python_d`即可打开新生成的 Python 3.7 解释器。
-
-
-
-
-## 更多内容
-更多关于在 Windows 上进行编译和开发 Python 的内容见[官方指南](https://devguide.python.org/setup/#windows-compiling)
diff --git a/docs/runtime/gil/allow-threads.svg b/docs/runtime/gil/allow-threads.svg
deleted file mode 100644
index 3be3c12..0000000
--- a/docs/runtime/gil/allow-threads.svg
+++ /dev/null
@@ -1,36 +0,0 @@
-
diff --git a/docs/runtime/gil/eval-breaker.svg b/docs/runtime/gil/eval-breaker.svg
deleted file mode 100644
index 7552439..0000000
--- a/docs/runtime/gil/eval-breaker.svg
+++ /dev/null
@@ -1,48 +0,0 @@
-
diff --git a/docs/runtime/gil/gil-baton.svg b/docs/runtime/gil/gil-baton.svg
deleted file mode 100644
index 302e337..0000000
--- a/docs/runtime/gil/gil-baton.svg
+++ /dev/null
@@ -1,44 +0,0 @@
-
diff --git a/docs/runtime/gil/gil-handoff.svg b/docs/runtime/gil/gil-handoff.svg
deleted file mode 100644
index b958dce..0000000
--- a/docs/runtime/gil/gil-handoff.svg
+++ /dev/null
@@ -1,47 +0,0 @@
-
diff --git a/docs/runtime/gil/gil-tradeoff.svg b/docs/runtime/gil/gil-tradeoff.svg
deleted file mode 100644
index dda7d36..0000000
--- a/docs/runtime/gil/gil-tradeoff.svg
+++ /dev/null
@@ -1,46 +0,0 @@
-
diff --git a/docs/runtime/gil/index.md b/docs/runtime/gil/index.md
deleted file mode 100644
index 48cd11f..0000000
--- a/docs/runtime/gil/index.md
+++ /dev/null
@@ -1,171 +0,0 @@
-# 多线程与 GIL
-
-`import` 让多个模块协作；而**多线程**让多段代码看似「同时」运行。但 Python 的线程有个声名远扬的脾气——那把 **GIL（Global Interpreter Lock，全局解释器锁）**。它常被骂「让多线程形同虚设」，又被赞「让 CPython 简单又快」。这一章，也是第五部分的收尾，我们就把它看个透彻：GIL **是什么、为什么存在、怎么工作、代价何在**。
-
-## 先看现象：多线程为何不加速 CPU 密集任务
-
-不谈原理，先看一个让很多人困惑的实验。开两个线程各跑一段纯计算，按直觉应该快一倍，结果却和单线程**几乎一样慢**：
-
-```python
->>> import time, threading
->>> def cpu_bound():
-... x = 0
-... for _ in range(30_000_000): x += 1
-...
->>> t0 = time.time(); cpu_bound(); cpu_bound(); print("顺序:", time.time()-t0)
-顺序: 2.01
->>> t0 = time.time()
->>> ts = [threading.Thread(target=cpu_bound) for _ in range(2)]
->>> [t.start() for t in ts]; [t.join() for t in ts]; print("两线程:", time.time()-t0)
-两线程: 2.03 # 没快！两个线程在抢同一把锁，本质还是轮流跑
-```
-
-可换成 **I/O 密集**任务（比如 `time.sleep`、网络请求），多线程又确实能重叠、能提速。这个反差正是理解 GIL 的入口：**GIL 让任意时刻只有一个线程在执行 Python 字节码，但线程在等 I/O 时会让出它**。
-
-## GIL 是什么：一根「执行权」的接力棒
-
-GIL 本质上就是一把**互斥锁**——准确说，是一个「锁标志 + 条件变量」的组合。它的状态记在运行时里：
-
-`源文件：`[Include/internal/gil.h](https://github.com/python/cpython/blob/v3.7.0/Include/internal/gil.h#L19)
-
-```c
-// Include/internal/gil.h —— GIL 的运行时状态（节选）
-struct _gil_runtime_state {
- unsigned long interval; // 切换间隔，默认 5000 微秒（5ms）
- _Py_atomic_address last_holder; // 上一个持有者（用于判断有没有发生过切换）
- _Py_atomic_int locked; // GIL 是否已被持有
- unsigned long switch_number; // 累计切换次数
- PyCOND_T cond; // 等待 GIL 释放的条件变量
- PyMUTEX_T mutex;
-};
-```
-
-规则只有一条，却管住了一切：**一个线程，必须先持有 GIL，才能执行字节码**。于是 GIL 就像一根**接力棒**——谁攥着它，谁才能跑求值循环；其他线程只能在一旁排队等棒。多核机器上你有 8 个线程，但因为只有一根棒，同一时刻**仍只有一个线程在真正执行 Python 代码**：
-
-
-
-这就解释了上面的实验：两个 CPU 密集线程，本质是在抢这根棒、轮流跑，加起来的工作量没变，自然不会更快。
-
-
-
-## 为什么需要 GIL：保护「不设防」的引用计数
-
-一个自然的问题是：为什么要给自己套上这么一把锁？答案藏在 CPython 的内存管理里——**引用计数**（下一部分的主题）。
-
-回想第二部分：每个对象都有个 `ob_refcnt`，增减引用时用 `Py_INCREF`/`Py_DECREF` 改它，归零就回收。问题是，**这俩操作不是原子的**：`Py_INCREF` 实质是「读出 refcnt → 加一 → 写回」三步。如果两个线程同时对一个对象 `INCREF`，可能双双读到旧值、各自加一、写回——**两次加一只生效了一次**。计数错误的后果是灾难性的：少计数会导致对象被**提前释放**（之后访问就是悬空指针、崩溃），多计数则导致**内存泄漏**。
-
-
-
-GIL 用最简单粗暴的方式根除了这个问题：**既然任意时刻只有一个线程在跑字节码，引用计数和所有解释器内部状态就天然安全**，无需给每个对象都加锁。另一条路——给每个对象配一把锁——不仅会让单线程程序也付出沉重的加锁开销，还极易死锁。GIL 是 CPython 在「简单 + 单线程快」和「多线程并行」之间做出的取舍：**牺牲多线程并行，换来实现简单、单线程高效、C 扩展易写**。
-
-## GIL 怎么切换：协作式的让棒
-
-既然只有一根棒，那它是怎么在线程间传递的？这是一套**协作式**机制，由两端配合完成。
-
-**等待端：超时就「催」。** 一个想要 GIL 的线程，在 `take_gil` 里等待持有者释放。它不会无限干等——而是定时等待 `interval`（默认 **5 毫秒**）。若超时了 GIL 仍被同一个线程攥着（期间没发生过切换），它就设置一个标志 `gil_drop_request`，相当于「**催**对方让棒」：
-
-`源文件：`[Python/ceval_gil.h](https://github.com/python/cpython/blob/v3.7.0/Python/ceval_gil.h#L191)
-
-```c
-// Python/ceval_gil.h —— take_gil（精简）
-while (gil.locked) {
- saved_switchnum = gil.switch_number;
- COND_TIMED_WAIT(gil.cond, gil.mutex, INTERVAL, timed_out); // 最多等 5ms
- if (timed_out && gil.locked && gil.switch_number == saved_switchnum) {
- SET_GIL_DROP_REQUEST(); // 等太久了：催当前持有者让棒
- }
-}
-// ……抢到棒：gil.locked = 1，更新 last_holder、switch_number
-```
-
-**持有端：到检查点就让。** 正在跑的线程不会被强行打断——它在求值循环里**主动**在检查点查看「有没有谁在催我」。一旦发现 `gil_drop_request`，就老老实实让棒（`drop_gil`）、给别人机会，再重新抢回来（`take_gil`）：
-
-`源文件：`[Python/ceval.c](https://github.com/python/cpython/blob/v3.7.0/Python/ceval.c#L967)
-
-```c
-// Python/ceval.c —— 求值循环里的让棒点（精简）
-if (_Py_atomic_load_relaxed(&_PyRuntime.ceval.gil_drop_request)) {
- /* Give another thread a chance */
- PyThreadState_Swap(NULL);
- drop_gil(tstate); // 放下棒
- /* Other threads may run now */
- take_gil(tstate); // 重新抢棒
- PyThreadState_Swap(tstate);
-}
-```
-
-
-
-合起来就是：**等待线程催（5ms 超时设标志）→ 持有线程在检查点主动让 → 别人抢到棒**。这个 5ms 就是 `sys.getswitchinterval()` 返回的「切换间隔」，可以调：
-
-```python
->>> import sys
->>> sys.getswitchinterval()
-0.005
->>> sys.setswitchinterval(0.001) # 调成 1ms：切换更勤，但切换开销也更多
-```
-
-> 这是 3.2 起的「新 GIL」——基于**时间**（5ms）。更早的旧 GIL 是基于**字节码条数**（每跑 100 条检查一次），在某些负载下切换很不公平，遂被时间式取代。
-
-## eval_breaker：一次廉价的检查，管住所有「待办」
-
-这里有个值得玩味的工程细节。「让棒」要在求值循环里频繁检查，可如果每执行一条字节码都去读 `gil_drop_request`、再读有没有信号、再读有没有待处理调用……每条指令都背上一串检查，太亏了。
-
-CPython 的办法是一个聚合标志 **`eval_breaker`**：只要**任何一件待办**发生（有人催让棒、收到信号、有待处理的回调、有异步异常），就把这一个标志置位。求值循环每轮只需做**一次廉价的原子读**——`eval_breaker` 没置位（绝大多数情况），就径直执行下一条指令；只有它置位了，才进去逐项核对到底是哪件事：
-
-`源文件：`[Python/ceval.c](https://github.com/python/cpython/blob/v3.7.0/Python/ceval.c#L943)
-
-```c
-// Python/ceval.c —— 求值循环顶部的统一检查点（精简）
-if (_Py_atomic_load_relaxed(&_PyRuntime.ceval.eval_breaker)) { // 一次廉价原子读
- if (...pending.calls_to_do...) Py_MakePendingCalls(); // 待处理回调
- if (...gil_drop_request...) { drop_gil(); take_gil(); } // 让棒（上一节）
- if (tstate->async_exc != NULL) { ...; goto error; } // 异步异常
-}
-fast_next_opcode:
- ... // 取下一条指令
-```
-
-
-
-这样一来，常态下多线程的「检查成本」几乎可以忽略，只有真有事时才付出代价。这也是为什么让棒是**协作式**的：线程只在这个检查点让棒，所以一条「不可中断」的长字节码（比如某些 C 实现的内建操作）跑起来时，GIL 是不会中途易手的。
-
-## I/O 与 C 扩展：主动放下棒
-
-回到开头那个反差：为什么 I/O 密集任务多线程能提速？因为**线程在做阻塞操作前会主动放下 GIL**。CPython 的惯用法是一对宏 `Py_BEGIN_ALLOW_THREADS` / `Py_END_ALLOW_THREADS`——把可能阻塞的系统调用（读文件、等网络、`time.sleep`）夹在中间，进去前 `drop_gil`、出来后 `take_gil`：
-
-
-
-```c
-// 典型的阻塞 I/O 写法（示意）
-Py_BEGIN_ALLOW_THREADS // 放下 GIL —— 别的线程现在能跑了
-ret = read(fd, buf, len); // 阻塞在这儿，但没占着棒
-Py_END_ALLOW_THREADS // 重新拿回 GIL
-```
-
-于是一个线程等 I/O 时，棒被别的线程拿去跑——I/O 的等待时间被**重叠**掉了。同理，NumPy 这类 C 扩展在做大块纯计算时也会释放 GIL，让多个线程真正并行算数。**所以「GIL 让多线程没用」并不准确**：它只挡住了**纯 Python 的 CPU 密集**并行，对 I/O 密集和「会释放 GIL 的 C 扩展」毫无妨碍。
-
-## 代价与出路
-
-GIL 的代价很明确：**纯 Python 的 CPU 密集任务，无法靠多线程吃满多核**。绕开它的常见办法有几条：
-
-
-
-- **I/O 密集**：放心用 `threading`，GIL 在 I/O 时会让出；
-- **CPU 密集**：用 `multiprocessing` 开**多进程**——每个进程有自己的解释器和 GIL，真正并行（代价是进程间通信开销）；
-- **重计算下沉到 C**：用会释放 GIL 的扩展（NumPy、加密库等）；
-- **更远的方向**：3.12 起的**子解释器**与 per-interpreter GIL，正朝着「一个进程内多个互不共享 GIL 的解释器」演进——但那是后话了。
-
-GIL 不是设计缺陷，而是一个**权衡**：它用「牺牲一种并行」换来了实现的简单、单线程的高效，以及与海量 C 扩展的轻松互操作。理不理解 GIL，往往就是「为什么我的多线程没变快」与「我该用线程还是进程」之间的分水岭。
-
----
-
-小结一下多线程与 GIL：
-
-- **GIL 是一把全局互斥锁**（`locked` 标志 + 条件变量），线程**必须持有它才能执行字节码**——像一根执行权接力棒，任意时刻只有一个线程在跑 Python 代码；
-- 它存在的根本原因是**保护非原子的引用计数**（及所有解释器内部状态）：没有 GIL，并发的 `Py_INCREF`/`Py_DECREF` 会算错计数，导致提前释放或泄漏；
-- 切换是**协作式**的：等待线程在 `take_gil` 里超时（默认 **5ms**）后设 `gil_drop_request`，持有线程在求值循环的检查点主动 `drop_gil` 让棒、再 `take_gil` 抢回；
-- **`eval_breaker`** 把「让棒、信号、待处理调用、异步异常」聚合成一个标志，让求值循环每轮只做一次廉价原子读——常态零负担；
-- 线程在**阻塞 I/O**和**会释放 GIL 的 C 扩展**里主动让棒，所以 I/O 密集与重 C 计算能真正并行；纯 Python 的 **CPU 密集**才是 GIL 的受限场景，出路是多进程或下沉到 C。
-
-至此，第五部分「运行时」就完整了：解释器如何初始化、如何 import 模块、多线程下 GIL 如何运转。这一路上，**引用计数**这个词反复出现——它是 GIL 之所以存在的根由，也是对象生死的裁决者。它究竟如何工作、又如何与「循环垃圾回收」配合？最后一部分「内存管理」，就从 **内存分配与引用计数** 讲起。
diff --git a/docs/runtime/gil/refcount-race.svg b/docs/runtime/gil/refcount-race.svg
deleted file mode 100644
index ee879b0..0000000
--- a/docs/runtime/gil/refcount-race.svg
+++ /dev/null
@@ -1,42 +0,0 @@
-
diff --git a/docs/runtime/gil/threads-no-speedup.svg b/docs/runtime/gil/threads-no-speedup.svg
deleted file mode 100644
index f3260f0..0000000
--- a/docs/runtime/gil/threads-no-speedup.svg
+++ /dev/null
@@ -1,49 +0,0 @@
-
diff --git a/docs/runtime/import-system/find-and-load-handoff.svg b/docs/runtime/import-system/find-and-load-handoff.svg
deleted file mode 100644
index 90ecec3..0000000
--- a/docs/runtime/import-system/find-and-load-handoff.svg
+++ /dev/null
@@ -1,38 +0,0 @@
-
diff --git a/docs/runtime/import-system/finder-loader-protocol.svg b/docs/runtime/import-system/finder-loader-protocol.svg
deleted file mode 100644
index 252134b..0000000
--- a/docs/runtime/import-system/finder-loader-protocol.svg
+++ /dev/null
@@ -1,54 +0,0 @@
-
diff --git a/docs/runtime/import-system/import-bytecode.svg b/docs/runtime/import-system/import-bytecode.svg
deleted file mode 100644
index 383f052..0000000
--- a/docs/runtime/import-system/import-bytecode.svg
+++ /dev/null
@@ -1,43 +0,0 @@
-
diff --git a/docs/runtime/import-system/import-is-call.svg b/docs/runtime/import-system/import-is-call.svg
deleted file mode 100644
index 7cec752..0000000
--- a/docs/runtime/import-system/import-is-call.svg
+++ /dev/null
@@ -1,46 +0,0 @@
-
diff --git a/docs/runtime/import-system/index.md b/docs/runtime/import-system/index.md
deleted file mode 100644
index 0558e96..0000000
--- a/docs/runtime/import-system/index.md
+++ /dev/null
@@ -1,210 +0,0 @@
-# 模块与 import 机制
-
-上一章我们看到，`importlib` 在初始化时被「自举」了起来——可它**怎么工作**，我们还没碰。这一章就来回答那个每天写无数遍、却很少深究的问题：当你敲下 `import numpy`，从这一刻到 `numpy` 这个名字出现在你的命名空间里，CPython 究竟做了什么？
-
-答案分成清晰的几层：`import` 语句其实是**一次函数调用**；调用先查一道**缓存**（`sys.modules`）；缓存未命中，才真正去**查找并加载**——而查找/加载这套活，交给了用 Python 写的 `importlib`，由一组 **finder** 和 **loader** 按协议完成。我们逐层拆开。
-
-## import 语句的真身：调用 __import__
-
-先看 `import` 编译成了什么。`import os` 的字节码骨架是：
-
-```
- LOAD_CONST 0 # level（相对导入层级，绝对导入为 0）
- LOAD_CONST None # fromlist（import os 时为 None）
- IMPORT_NAME os # ★ 真正干活的指令
- STORE_NAME os # 把得到的模块对象绑定到名字 os
-```
-
-核心是 `IMPORT_NAME`。而它做的第一件事出人意料——**去 `builtins` 里取出 `__import__` 函数来调用**：
-
-`源文件：`[Python/ceval.c](https://github.com/python/cpython/blob/v3.7.0/Python/ceval.c#L4722)
-
-```c
-// Python/ceval.c —— import_name（IMPORT_NAME 的实现，精简）
-import_func = _PyDict_GetItemId(f->f_builtins, &PyId___import__); // 取 builtins.__import__
-if (import_func == NULL) { PyErr_SetString(...); return NULL; }
-// 快路径：未被覆盖的 __import__ 直接调底层 C 实现
-if (import_func == interp->import_func) {
- return PyImport_ImportModuleLevelObject(name, f->f_globals, f->f_locals, fromlist, ilevel);
-}
-// 否则当成普通函数调用（支持自定义 __import__）
-res = _PyObject_FastCall(import_func, stack, 5);
-```
-
-这揭示了一个常被忽视的事实：**`import X` 本质等价于 `X = __import__('X', ...)`**。`__import__` 是个普通的内建函数，因此**可以被替换**——这正是一些导入钩子、沙箱、惰性导入库的工作原理：
-
-
-
-```python
->>> import builtins
->>> original = builtins.__import__
->>> def traced(name, *args, **kw):
-... print("正在导入:", name)
-... return original(name, *args, **kw)
-...
->>> builtins.__import__ = traced
->>> import json # 触发我们的钩子
-正在导入: json
->>> builtins.__import__ = original # 还原
-```
-
-`from os import getcwd` 则多一步：`IMPORT_NAME` 带上 `fromlist=('getcwd',)` 拿到模块，再用 `IMPORT_FROM` 从模块里取出 `getcwd` 这个属性；`from os import *` 走的是 `IMPORT_STAR`。但它们的起点都是同一个 `IMPORT_NAME`：
-
-
-
-## 第一道关卡：sys.modules 缓存
-
-未被覆盖时，`IMPORT_NAME` 落到 C 实现 `PyImport_ImportModuleLevelObject`。它在真正去加载之前，先查一道至关重要的缓存——**`sys.modules`**，一个「模块名 → 模块对象」的字典：
-
-`源文件：`[Python/import.c](https://github.com/python/cpython/blob/v3.7.0/Python/import.c#L1671)
-
-```c
-// Python/import.c —— PyImport_ImportModuleLevelObject（精简主干）
-abs_name = resolve_name(name, globals, level); // 解析成绝对模块名
-mod = _PyImport_GetModule(abs_name); // ★ 先查 sys.modules
-if (mod != NULL && mod != Py_None) {
- // 命中缓存：直接用，绝不重复加载
-}
-else {
- mod = import_find_and_load(abs_name); // 未命中：才去查找并加载
-}
-```
-
-
-
-这道缓存解释了几个日常现象：
-
-- **模块顶层代码只执行一次**。第二次 `import os`，命中缓存直接返回，`os.py` 的顶层代码不会再跑：
-
-```python
->>> import sys
->>> 'json' in sys.modules
-False
->>> import json
->>> 'json' in sys.modules # 加载后进了缓存
-True
->>> import json as j
->>> j is sys.modules['json'] # 再次 import 拿到的是缓存里同一个对象
-True
-```
-
-- **循环导入能「半工作」**。加载一个模块时，CPython 会**先把半成品模块放进 `sys.modules`、再执行它的代码**。于是当 A 导入 B、B 又回头导入 A 时，B 拿到的是那个还没执行完的 A 半成品——不会无限递归，但可能读到尚未定义的名字。这个「先登记后执行」的顺序是循环导入行为的根源，下面加载流程里还会再点到。
-
-## 缓存未命中：C 把活儿交给 importlib
-
-缓存没命中，`import_find_and_load` 出场。它的实现短得惊人——**把活儿原样转交给用 Python 写的 `importlib`**：
-
-`源文件：`[Python/import.c](https://github.com/python/cpython/blob/v3.7.0/Python/import.c#L1615)
-
-```c
-// Python/import.c —— import_find_and_load（精简）
-PyInterpreterState *interp = PyThreadState_GET()->interp;
-mod = _PyObject_CallMethodIdObjArgs(interp->importlib, // 上一章自举出的 importlib
- &PyId__find_and_load, // 调它的 _find_and_load
- abs_name, interp->import_func, NULL);
-return mod;
-```
-
-这是一处精彩的分工：**C 层只管「查缓存」这种性能敏感的快路径，真正复杂多变的查找/加载逻辑，全用 Python 写在 `importlib._bootstrap` 里**。用 Python 实现 import，让它易读、易改、易扩展——代价（每次加载的开销）由前面的 `sys.modules` 缓存兜住了。
-
-
-
-## finder 与 loader：两段式加载协议
-
-进了 `importlib`，`_find_and_load` 把「导入一个模块」拆成**两段**，由两类角色分工：
-
-- **finder（查找器）**：回答「这个模块在哪、该用什么方式加载」，产出一个 **`ModuleSpec`**（导入规格，内含一个 loader）；
-- **loader（加载器）**：回答「把模块**真正建出来**」，执行模块代码、填充模块对象。
-
-
-
-整个流程是这样（`importlib._bootstrap` 的逻辑，简化）：
-
-```python
-# importlib._bootstrap._find_and_load 的骨架（示意）
-def _find_and_load(name, import_):
- spec = _find_spec(name, ...) # ① 遍历 finder 找到 spec
- module = module_from_spec(spec) # ② 按 spec 造出空模块对象
- sys.modules[name] = module # ③ ★ 先登记，再执行（循环导入靠这步）
- spec.loader.exec_module(module) # ④ 在模块的 __dict__ 里执行其代码
- return module
-```
-
-第 ④ 步 `exec_module` 把模块源码编译成 code object、在模块自己的名字空间（`module.__dict__`）里跑一遍——这就回到了前面几部分讲的编译与求值：**模块的顶层代码，也是在一个帧里执行的**，只不过那个帧的全局名字空间就是这个模块的 `__dict__`。注意第 ③ 步在 ④ **之前**，这正是上一节「先登记后执行」的落点。
-
-## meta_path：到哪去找 finder
-
-那么 `_find_spec` 是怎么找到合适 finder 的？它依次问 **`sys.meta_path`** 上的每一个 finder：「你认识这个模块吗？」谁先返回非空的 spec，就用谁。默认的 `sys.meta_path` 上有三位：
-
-
-
-```python
->>> import sys
->>> sys.meta_path
-[