后端【免费下载链接】geventCoroutine-based concurrency library for Python项目地址https://gitcode.com/gh_mirrors/ge/gevent点击查看免费下载导读gevent 是一个基于协程coroutine的 Python 并发库其事件循环与 DNS 解析能力并非完全自研而是建立在 libev / libuv 与 c-ares 三个成熟的 C 库之上。为了保证跨平台构建的确定性、避免版本漂移带来的兼容性风险gevent 采用了内嵌vendoring/embedding依赖的策略把三个 C 库的源码直接放入仓库的deps/目录并配合构建脚本一起打包。本文基于仓库中的 deps/README.rst 操作手册完整梳理三个依赖的更新流程、需要清理的冗余文件、必须修补的关键点并结合 _setuplibev.py、_setupares.py、src/gevent/libuv/_corecffi_build.py 等构建脚本解释每一步操作背后的工程原因。读完本文你将能够独立完成一次 gevent 内嵌依赖的升级并知道如何验证升级结果。一、为什么 gevent 要内嵌这三个 C 库在深入了解更新流程之前先看清deps/目录里到底放的是什么deps/libev/libev 事件循环库被gevent.libev后端使用deps/c-ares/c-ares 异步 DNS 解析库被gevent.resolver.cares使用deps/libuv/libuv 事件循环库被gevent.libuv后端使用deps/greenlet/仅保留头文件greenlet.h的内嵌依赖deps/cares-make.patch针对 c-ares 构建系统的本地补丁。构建脚本里可以清楚看到内嵌与外链两种模式的切换逻辑。以 _setuplibev.py 为例should_embed(libev)决定是否内嵌内嵌时把deps/libev加入 include 路径并附带LIBEV_EMBED1、EV_USE_REALTIME1、EV_USE_MONOTONIC1等宏定义非内嵌模式则直接链接系统库ev见_setuplibev.py的else分支CORE.libraries.append(ev)。_setupares.py 同理内嵌时把deps/c-ares/src/lib下各子目录的.c文件全部加入编译源列表并定义CARES_EMBED1、HAVE_CONFIG_HWindows 上为CARES_STATICLIB非内嵌时链接系统cares库。src/gevent/libuv/_corecffi_build.py 则按平台把 libuv 的src/fs-poll.c、src/uv-common.c、src/threadpool.c等公共源文件与src/unix/*.c、src/win/*.c平台源文件组织进 CFFI 编译。正因为源码被直接内嵌并参与编译上游库的每次升级都会直接影响 gevent 的构建产物。因此更新过程绝不是解压覆盖这么简单而是一套有纪律的清理、修补、提交流程。二、通用原则用最小化补丁表达本地修改deps/README.rst开篇就给出了贯穿整个流程的第一条铁律Generate patches withgit diff --patch --minimal -b即本地对上游源码的一切改动都应通过 git 补丁来记录且补丁要满足三个要求--patch以补丁格式输出差异便于复用与审查--minimal让 diff 算法尽量生成最小的变更集减少补丁与上游新版本的冲突面-b忽略空白的差异仅比较非空白字符避免因上游重排空格导致补丁失效。这条原则在 c-ares 的更新流程中体现得最充分见下文第四节deps/cares-make.patch就是遵循该原则产出的补丁样例——它只改动了Makefile.am、Makefile.in、configure、configure.ac四个文件中的少量行把docs、test子目录从构建和分发列表里剔除。三、更新 libevlibev 的更新流程相对简单核心是瘦身下载并解压官方 tarball 到deps/libev/然后删除构建内嵌版本不需要的冗余文件rm -f libev/Makefile.am rm -f libev/Symbols.ev rm -f libev/Symbols.event rm -f libev/TODO rm -f libev/aclocal.m4 rm -f libev/autogen.sh rm -f libev/compile rm -f libev/configure.ac rm -f libev/libev.m4 rm -f libev/mkinstalldirs删除这些文件的原因从当前仓库 deps/libev 目录清单可以印证gevent 内嵌 libev 时不需要 autotools 的生成链路autogen.sh、aclocal.m4、configure.ac、Makefile.am、libev.m4、compile、mkinstalldirs也不需要符号导出脚本Symbols.ev、Symbols.event与上游 TODO。保留的是configure、config.h.in、Makefile.in以及ev.c、ev.h、各平台后端源文件ev_epoll.c、ev_kqueue.c、ev_poll.c、ev_select.c等。清理之后检查config.guess和config.sub是否时间倒流详见第五节。一个值得注意的细节_setuplibev.py 的configure_libev()会在构建时于deps/libev/内执行sh ./configure -C生成config.h如果config.h已存在则跳过配置。因此升级后首次构建时旧版本的config.h可能残留必要时需要清理后再触发配置。四、更新 c-ares最复杂的流程c-ares 的更新是全流程中最繁琐的一步原因在于它不仅要清理文件还要应用本地补丁cares-make.patch。完整命令序列如下可直接复制到终端执行注意先进入deps/目录export CARES_VER1.33.1 cd deps/ wget https://github.com/c-ares/c-ares/releases/download/v$CARES_VER/c-ares-$CARES_VER.tar.gz tar -xf c-ares-$CARES_VER.tar.gz rm -rf c-ares c-ares-$CARES_VER.tar.gz mv c-ares-$CARES_VER c-ares cp c-ares/include/ares_build.h c-ares/include/ares_build.h.dist rm -rf c-ares/docs rm -rf c-ares/test rm -rf c-ares/cmake rm -f c-ares/maketgz rm -f c-ares/CMakeLists.txt rm -f c-ares/RELEASE-PROCEDURE.md c-ares/CONTRIBUTING.md c-ares/SECURITY.md rm -f c-ares/*.cmake c-ares/*.cmake.in rm -rf c-ares/config/ rm -f c-ares/INSTALL.md c-ares/LICENSE.md c-ares/DEVELOPER-NOTES.md rm -f c-ares/buildconf.bat rm -f c-ares/Makefile* git apply cares-make.patch逐段解读这套操作的目的cp include/ares_build.h include/ares_build.h.distares_build.h是 configure 生成的平台相关头文件上游分发的.dist版本被 gevent 保留下来。_setupares.py 在 Windows 上正是直接拷贝deps/c-ares/include/ares_build.h.dist到构建目录作为ares_build.h使用的。删除docs、test、cmake等目录内嵌版本不携带文档与上游测试套件避免污染 sdist 发行包体积。删除Makefile*后应用补丁cares-make.patch针对Makefile.am、Makefile.in、configure、configure.ac四个文件把DIST_SUBDIRS/BUILD_SUBDIRS中的docs、test子目录移除。查看 deps/cares-make.patch 可见其具体改动DIST_SUBDIRS include src test docs改为include srcBUILD_SUBDIRSinclude src docs改为include src并同步删除了docs/Makefile的生成条目——这样上游自带的 MANPAGES 文档就不会被打进 gevent 的 sdist。补丁应用后还有两个重要后续评估新增文件新版本 c-ares 中可能产生需要纳入 git 与构建的新文件逐一评估后git add补丁冲突处理若git apply失败先把当前改动git commit原文强调 commit the changes before the patch然后手工编辑三个目标文件按现有补丁文件的模式搜索定位相关行删除对docs和test的引用修复后重新生成补丁git diff -p --minimal -w注意原文特别警告不能把这条命令的输出直接重定向到cares-make.patch——否则会把补丁本身的 diff也卷进新补丁造成自引用污染。最后c-ares 同样要执行config.guess/config.sub的时间检查只是这两个文件位于config/子目录当前仓库的 deps/c-ares/config 目录即包含config.guess与config.sub。五、更新 libuv平台细节最多libuv 的更新命令序列同样设计为复制粘贴即可执行export LIBUV_VERv1.38.0 cd deps/ wget https://dist.libuv.org/dist/$LIBUV_VER/libuv-$LIBUV_VER.tar.gz tar -xf libuv-$LIBUV_VER.tar.gz rm libuv-$LIBUV_VER.tar.gz rm -rf libuv mv libuv-$LIBUV_VER libuv rm -rf libuv/.github rm -rf libuv/.readthedocs.yaml rm -rf libuv/LINKS.md rm -rf libuv/docs rm -rf libuv/samples rm -rf libuv/test/*.[ch] libuv/test/test.gyp # must leave the fixtures/ dir rm -rf libuv/tools rm -f libuv/android-configure* rm -f libuv/uv_win_longpath.manifest rm -rf libuv/cmake-toolchains/几个要点需要单独说明libuv/test/*.[ch]与test.gyp删除但必须保留test/fixtures/目录因为 src/gevent/libuv/_corecffi_build.py 编译时并不需要测试源文件但仓库中依赖测试夹具文件用于 gevent 的测试套件所以命令末尾特意注释 must leave the fixtures/ dir。评估构建系统变更解压后检查 libuv 是否有新的源文件需要加入 git 与构建流程必要时同步修改 src/gevent/libuv/_corecffi_build.py 中的LIBUV_SOURCES列表该文件按 Linux / Darwin / FreeBSD / OpenBSD / NetBSD / SunOS / AIX / Haiku / Cygwin / Windows 分别组织源文件。同时留意上游构建系统如.gyp文件的变动看是否需要反映到 gevent 自己的构建文件里。m4目录的特殊警告原文以caution形式给出要特别注意libuv/m4目录——新增的.m4文件可能不会出现在git status输出中详见上游 libuv issue 2862 的已知问题因此清理后要手动核对m4/下是否有新文件需要入库。当前仓库 deps/libuv/m4 中确实保留了一批ax_*.m4、libuv-*.m4等 autoconf 宏文件升级时务必逐一对账。config.guess/config.sub与 libev 相同的检查步骤。5.1 libuv 1.49 的 kqueue 定向修改从 libuv 1.49 开始必须手工编辑deps/libuv/src/unix/kqueue.c在函数uv__io_check_fd中有两段针对 FreeBSD 与 AppleDarwin平台检查文件描述符类型、对普通文件和管道返回EINVAL的代码块需要用#if 0将其禁用。为什么要禁用原文档给出的解释很直白如果不做这个修改gevent 的test__fileobject.py测试会失败——gevent 实际测试的使用场景并不涉及上游这两段代码所修复的问题而这些检查会把 gevent 支持的场景如对普通文件/管道 fd 做事件监听直接拒绝掉。这个修改在当前仓库中有真实落点deps/libuv/src/unix/kqueue.c 的uv__io_check_fd函数里可以看到#if 0 /* gevent: These things work fine in our tested use cases. */的注释包裹着S_ISREG/S_ISDIR返回UV_EINVAL以及__APPLE__下S_ISFIFO的检查代码。这也提醒升级者升级后应通过git diff确认这类本地补丁是否仍被正确保留。六、config.guess / config.sub 的时间倒流检查这是 libev、c-ares、libuv 三个依赖共用的一个检查步骤Check if config.guess and/or config.sub went backwards in time (the timestamp and copyright dates). If so, revert it (or update from the latest source).config.guess/config.sub是 GNU 标准的系统类型探测脚本包含版本时间戳与版权年份例如当前仓库 deps/c-ares/config/config.guess 首部标注 Copyright 1992-2024 Free Software Foundation。由于各上游仓库打包的这两个脚本版本新旧不一解压新版本后可能出现比 gevent 仓库中已有的版本更旧的情况went backwards in time。遇到这种情况应回退revert到较新的版本或从 GNU config 的最新源更新。c-ares 版本中的这两个文件位于config/子目录libev 与 libuv 版本中位于各自目录根下处理时注意路径差异。七、升级后的收尾与验证三个依赖各自的清理与修补完成后还需要做一轮系统性收尾git 入库将新增的源文件、.m4宏文件、头文件等逐项评估后加入版本控制对 c-ares 还需确认补丁应用后生成的cares-make.patch与仓库现状一致。构建脚本同步对照上游新版本的目录结构检查 _setuplibev.py、_setupares.py、src/gevent/libuv/_corecffi_build.py 中的源文件列表、宏定义与库依赖是否需要更新。测试验证运行 gevent 的测试套件重点观察与对应依赖相关的测试例如文件对象相关的 src/gevent/tests/test__fileobject.pylibuv kqueue 修改的验收测试、DNS 解析相关的 src/gevent/tests/test__socket_dns.py 与 src/gevent/tests/test__resolver_dnspython.pyc-ares 相关等。确认本地补丁存活升级本质上是上游代码 本地补丁的合并用git diff复查#if 0、cares-make.patch对应的改动是否在覆盖新 tarball 后依然生效。八、小结gevent 的内嵌依赖管理可以总结为三条纪律有选择地保留只保留构建所需的最小文件集删除 autotools 生成链、文档、上游测试、CMake 工程等冗余内容保证 sdist 干净、构建确定补丁最小化所有本地改动以git diff --patch --minimal -b/-p --minimal -w形式沉淀为可复用的补丁减少与上游新版本的冲突面平台差异显式化libuv 的 kqueue 修正、c-ares 的ares_build.h.dist保留、Windows 的CARES_STATICLIB宏等平台特化处理全部落在构建脚本与补丁中保证跨平台一致性。掌握 deps/README.rst 这套流程后当 gevent 需要跟进上游 libev / c-ares / libuv 的新版本时你就能按照同一套可复现的步骤完成升级并借助git diff与测试套件验证每一步的改动是否符合预期。赞分享后端【免费下载链接】geventCoroutine-based concurrency library for Python项目地址https://gitcode.com/gh_mirrors/ge/gevent点击查看免费下载相关推荐终极gevent事件循环指南从入门到精通的libev与libuv实战选择终极gevent事件循环指南从入门到精通的libev与libuv实战选择 gevent是一个基于协程的Python并发库提供了高效的事件循环机制。本文将深入后端gevent 协程并发网络库完全指南greenlet 与 libev/libuv 事件循环架构、安装与实战gevent 协程并发网络库完全指南greenlet 与 libev/libuv 事件循环架构、安装与实战 gevent 是一个基于协程coroutine后端gevent 嵌入的 c-ares基于 C 的异步 DNS 解析器解析、安全设计与集成实战gevent 嵌入的 c ares基于 C 的异步 DNS 解析器解析、安全设计与集成实战 导读 本文以 deps/c ares/README.md htt后端上一篇蓄水池抽样Reservoir Sampling算法详解流式数据等概率随机选取的原理、证明与实战下一篇CANN ops-math 算子实战aclnnFmodTensor 与 aclnnInplaceFmodTensor 张量取余接口全解析创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考