：libev、c-ares 與 libuv 的更新與維護全流程)
后端【免費下載鏈接】geventCoroutine-based concurrency library for Python項目地址https://gitcode.com/gh_mirrors/ge/gevent點擊查看免費下載導讀gevent 是一個基于協(xié)程coroutine的 Python 并發(fā)庫其事件循環(huán)與 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 事件循環(huán)庫被gevent.libev后端使用deps/c-ares/c-ares 異步 DNS 解析庫被gevent.resolver.cares使用deps/libuv/libuv 事件循環(huán)庫被gevent.libuv后端使用deps/greenlet/僅保留頭文件greenlet.h的內嵌依賴deps/cares-make.patch針對 c-ares 構建系統(tǒng)的本地補丁。構建腳本里可以清楚看到內嵌與外鏈兩種模式的切換邏輯。以 _setuplibev.py 為例should_embed(libev)決定是否內嵌內嵌時把deps/libev加入 include 路徑并附帶LIBEV_EMBED1、EV_USE_REALTIME1、EV_USE_MONOTONIC1等宏定義非內嵌模式則直接鏈接系統(tǒng)庫ev見_setuplibev.py的else分支CORE.libraries.append(ev)。_setupares.py 同理內嵌時把deps/c-ares/src/lib下各子目錄的.c文件全部加入編譯源列表并定義CARES_EMBED1、HAVE_CONFIG_HWindows 上為CARES_STATICLIB非內嵌時鏈接系統(tǒng)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 的構建產(chǎn)物。因此更新過程絕不是解壓覆蓋這么簡單而是一套有紀律的清理、修補、提交流程。二、通用原則用最小化補丁表達本地修改deps/README.rst開篇就給出了貫穿整個流程的第一條鐵律Generate patches withgit diff --patch --minimal -b即本地對上游源碼的一切改動都應通過 git 補丁來記錄且補丁要滿足三個要求--patch以補丁格式輸出差異便于復用與審查--minimal讓 diff 算法盡量生成最小的變更集減少補丁與上游新版本的沖突面-b忽略空白的差異僅比較非空白字符避免因上游重排空格導致補丁失效。這條原則在 c-ares 的更新流程中體現(xiàn)得最充分見下文第四節(jié)deps/cares-make.patch就是遵循該原則產(chǎn)出的補丁樣例——它只改動了Makefile.am、Makefile.in、configure、configure.ac四個文件中的少量行把docs、test子目錄從構建和分發(fā)列表里剔除。三、更新 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是否時間倒流詳見第五節(jié)。一個值得注意的細節(jié)_setuplibev.py 的configure_libev()會在構建時于deps/libev/內執(zhí)行sh ./configure -C生成config.h如果config.h已存在則跳過配置。因此升級后首次構建時舊版本的config.h可能殘留必要時需要清理后再觸發(fā)配置。四、更新 c-ares最復雜的流程c-ares 的更新是全流程中最繁瑣的一步原因在于它不僅要清理文件還要應用本地補丁cares-make.patch。完整命令序列如下可直接復制到終端執(zhí)行注意先進入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 生成的平臺相關頭文件上游分發(fā)的.dist版本被 gevent 保留下來。_setupares.py 在 Windows 上正是直接拷貝deps/c-ares/include/ares_build.h.dist到構建目錄作為ares_build.h使用的。刪除docs、test、cmake等目錄內嵌版本不攜帶文檔與上游測試套件避免污染 sdist 發(fā)行包體積。刪除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。補丁應用后還有兩個重要后續(xù)評估新增文件新版本 c-ares 中可能產(chǎn)生需要納入 git 與構建的新文件逐一評估后git add補丁沖突處理若git apply失敗先把當前改動git commit原文強調 commit the changes before the patch然后手工編輯三個目標文件按現(xiàn)有補丁文件的模式搜索定位相關行刪除對docs和test的引用修復后重新生成補丁git diff -p --minimal -w注意原文特別警告不能把這條命令的輸出直接重定向到cares-make.patch——否則會把補丁本身的 diff也卷進新補丁造成自引用污染。最后c-ares 同樣要執(zhí)行config.guess/config.sub的時間檢查只是這兩個文件位于config/子目錄當前倉庫的 deps/c-ares/config 目錄即包含config.guess與config.sub。五、更新 libuv平臺細節(jié)最多l(xiāng)ibuv 的更新命令序列同樣設計為復制粘貼即可執(zhí)行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。評估構建系統(tǒng)變更解壓后檢查 libuv 是否有新的源文件需要加入 git 與構建流程必要時同步修改 src/gevent/libuv/_corecffi_build.py 中的LIBUV_SOURCES列表該文件按 Linux / Darwin / FreeBSD / OpenBSD / NetBSD / SunOS / AIX / Haiku / Cygwin / Windows 分別組織源文件。同時留意上游構建系統(tǒng)如.gyp文件的變動看是否需要反映到 gevent 自己的構建文件里。m4目錄的特殊警告原文以caution形式給出要特別注意libuv/m4目錄——新增的.m4文件可能不會出現(xiàn)在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在函數(shù)uv__io_check_fd中有兩段針對 FreeBSD 與 AppleDarwin平臺檢查文件描述符類型、對普通文件和管道返回EINVAL的代碼塊需要用#if 0將其禁用。為什么要禁用原文檔給出的解釋很直白如果不做這個修改gevent 的test__fileobject.py測試會失敗——gevent 實際測試的使用場景并不涉及上游這兩段代碼所修復的問題而這些檢查會把 gevent 支持的場景如對普通文件/管道 fd 做事件監(jiān)聽直接拒絕掉。這個修改在當前倉庫中有真實落點deps/libuv/src/unix/kqueue.c 的uv__io_check_fd函數(shù)里可以看到#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 標準的系統(tǒng)類型探測腳本包含版本時間戳與版權年份例如當前倉庫 deps/c-ares/config/config.guess 首部標注 Copyright 1992-2024 Free Software Foundation。由于各上游倉庫打包的這兩個腳本版本新舊不一解壓新版本后可能出現(xiàn)比 gevent 倉庫中已有的版本更舊的情況went backwards in time。遇到這種情況應回退revert到較新的版本或從 GNU config 的最新源更新。c-ares 版本中的這兩個文件位于config/子目錄libev 與 libuv 版本中位于各自目錄根下處理時注意路徑差異。七、升級后的收尾與驗證三個依賴各自的清理與修補完成后還需要做一輪系統(tǒng)性收尾git 入庫將新增的源文件、.m4宏文件、頭文件等逐項評估后加入版本控制對 c-ares 還需確認補丁應用后生成的cares-make.patch與倉庫現(xiàn)狀一致。構建腳本同步對照上游新版本的目錄結構檢查 _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 的新版本時你就能按照同一套可復現(xiàn)的步驟完成升級并借助git diff與測試套件驗證每一步的改動是否符合預期。贊分享后端【免費下載鏈接】geventCoroutine-based concurrency library for Python項目地址https://gitcode.com/gh_mirrors/ge/gevent點擊查看免費下載相關推薦終極gevent事件循環(huán)指南從入門到精通的libev與libuv實戰(zhàn)選擇終極gevent事件循環(huán)指南從入門到精通的libev與libuv實戰(zhàn)選擇 gevent是一個基于協(xié)程的Python并發(fā)庫提供了高效的事件循環(huán)機制。本文將深入后端gevent 協(xié)程并發(fā)網(wǎng)絡庫完全指南greenlet 與 libev/libuv 事件循環(huán)架構、安裝與實戰(zhàn)gevent 協(xié)程并發(fā)網(wǎng)絡庫完全指南greenlet 與 libev/libuv 事件循環(huán)架構、安裝與實戰(zhàn) gevent 是一個基于協(xié)程coroutine后端gevent 嵌入的 c-ares基于 C 的異步 DNS 解析器解析、安全設計與集成實戰(zhàn)gevent 嵌入的 c ares基于 C 的異步 DNS 解析器解析、安全設計與集成實戰(zhàn) 導讀 本文以 deps/c ares/README.md htt后端上一篇蓄水池抽樣Reservoir Sampling算法詳解流式數(shù)據(jù)等概率隨機選取的原理、證明與實戰(zhàn)下一篇CANN ops-math 算子實戰(zhàn)aclnnFmodTensor 與 aclnnInplaceFmodTensor 張量取余接口全解析創(chuàng)作聲明：本文部分內容由AI輔助生成（AIGC），僅供參考 gevent 內嵌依賴管理實戰(zhàn)：libev、c-ares 與 libuv 的更新與維護全流程
后端【免費下載鏈接】geventCoroutine-based concurrency library for Python項目地址https://gitcode.com/gh_mirrors/ge/gevent點擊查看免費下載導讀gevent 是一個基于協(xié)程coroutine的 Python 并發(fā)庫其事件循環(huán)與 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 事件循環(huán)庫被gevent.libev后端使用deps/c-ares/c-ares 異步 DNS 解析庫被gevent.resolver.cares使用deps/libuv/libuv 事件循環(huán)庫被gevent.libuv后端使用deps/greenlet/僅保留頭文件greenlet.h的內嵌依賴deps/cares-make.patch針對 c-ares 構建系統(tǒng)的本地補丁。構建腳本里可以清楚看到內嵌與外鏈兩種模式的切換邏輯。以 _setuplibev.py 為例should_embed(libev)決定是否內嵌內嵌時把deps/libev加入 include 路徑并附帶LIBEV_EMBED1、EV_USE_REALTIME1、EV_USE_MONOTONIC1等宏定義非內嵌模式則直接鏈接系統(tǒng)庫ev見_setuplibev.py的else分支CORE.libraries.append(ev)。_setupares.py 同理內嵌時把deps/c-ares/src/lib下各子目錄的.c文件全部加入編譯源列表并定義CARES_EMBED1、HAVE_CONFIG_HWindows 上為CARES_STATICLIB非內嵌時鏈接系統(tǒng)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 的構建產(chǎn)物。因此更新過程絕不是解壓覆蓋這么簡單而是一套有紀律的清理、修補、提交流程。二、通用原則用最小化補丁表達本地修改deps/README.rst開篇就給出了貫穿整個流程的第一條鐵律Generate patches withgit diff --patch --minimal -b即本地對上游源碼的一切改動都應通過 git 補丁來記錄且補丁要滿足三個要求--patch以補丁格式輸出差異便于復用與審查--minimal讓 diff 算法盡量生成最小的變更集減少補丁與上游新版本的沖突面-b忽略空白的差異僅比較非空白字符避免因上游重排空格導致補丁失效。這條原則在 c-ares 的更新流程中體現(xiàn)得最充分見下文第四節(jié)deps/cares-make.patch就是遵循該原則產(chǎn)出的補丁樣例——它只改動了Makefile.am、Makefile.in、configure、configure.ac四個文件中的少量行把docs、test子目錄從構建和分發(fā)列表里剔除。三、更新 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是否時間倒流詳見第五節(jié)。一個值得注意的細節(jié)_setuplibev.py 的configure_libev()會在構建時于deps/libev/內執(zhí)行sh ./configure -C生成config.h如果config.h已存在則跳過配置。因此升級后首次構建時舊版本的config.h可能殘留必要時需要清理后再觸發(fā)配置。四、更新 c-ares最復雜的流程c-ares 的更新是全流程中最繁瑣的一步原因在于它不僅要清理文件還要應用本地補丁cares-make.patch。完整命令序列如下可直接復制到終端執(zhí)行注意先進入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 生成的平臺相關頭文件上游分發(fā)的.dist版本被 gevent 保留下來。_setupares.py 在 Windows 上正是直接拷貝deps/c-ares/include/ares_build.h.dist到構建目錄作為ares_build.h使用的。刪除docs、test、cmake等目錄內嵌版本不攜帶文檔與上游測試套件避免污染 sdist 發(fā)行包體積。刪除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。補丁應用后還有兩個重要后續(xù)評估新增文件新版本 c-ares 中可能產(chǎn)生需要納入 git 與構建的新文件逐一評估后git add補丁沖突處理若git apply失敗先把當前改動git commit原文強調 commit the changes before the patch然后手工編輯三個目標文件按現(xiàn)有補丁文件的模式搜索定位相關行刪除對docs和test的引用修復后重新生成補丁git diff -p --minimal -w注意原文特別警告不能把這條命令的輸出直接重定向到cares-make.patch——否則會把補丁本身的 diff也卷進新補丁造成自引用污染。最后c-ares 同樣要執(zhí)行config.guess/config.sub的時間檢查只是這兩個文件位于config/子目錄當前倉庫的 deps/c-ares/config 目錄即包含config.guess與config.sub。五、更新 libuv平臺細節(jié)最多l(xiāng)ibuv 的更新命令序列同樣設計為復制粘貼即可執(zhí)行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。評估構建系統(tǒng)變更解壓后檢查 libuv 是否有新的源文件需要加入 git 與構建流程必要時同步修改 src/gevent/libuv/_corecffi_build.py 中的LIBUV_SOURCES列表該文件按 Linux / Darwin / FreeBSD / OpenBSD / NetBSD / SunOS / AIX / Haiku / Cygwin / Windows 分別組織源文件。同時留意上游構建系統(tǒng)如.gyp文件的變動看是否需要反映到 gevent 自己的構建文件里。m4目錄的特殊警告原文以caution形式給出要特別注意libuv/m4目錄——新增的.m4文件可能不會出現(xiàn)在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在函數(shù)uv__io_check_fd中有兩段針對 FreeBSD 與 AppleDarwin平臺檢查文件描述符類型、對普通文件和管道返回EINVAL的代碼塊需要用#if 0將其禁用。為什么要禁用原文檔給出的解釋很直白如果不做這個修改gevent 的test__fileobject.py測試會失敗——gevent 實際測試的使用場景并不涉及上游這兩段代碼所修復的問題而這些檢查會把 gevent 支持的場景如對普通文件/管道 fd 做事件監(jiān)聽直接拒絕掉。這個修改在當前倉庫中有真實落點deps/libuv/src/unix/kqueue.c 的uv__io_check_fd函數(shù)里可以看到#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 標準的系統(tǒng)類型探測腳本包含版本時間戳與版權年份例如當前倉庫 deps/c-ares/config/config.guess 首部標注 Copyright 1992-2024 Free Software Foundation。由于各上游倉庫打包的這兩個腳本版本新舊不一解壓新版本后可能出現(xiàn)比 gevent 倉庫中已有的版本更舊的情況went backwards in time。遇到這種情況應回退revert到較新的版本或從 GNU config 的最新源更新。c-ares 版本中的這兩個文件位于config/子目錄libev 與 libuv 版本中位于各自目錄根下處理時注意路徑差異。七、升級后的收尾與驗證三個依賴各自的清理與修補完成后還需要做一輪系統(tǒng)性收尾git 入庫將新增的源文件、.m4宏文件、頭文件等逐項評估后加入版本控制對 c-ares 還需確認補丁應用后生成的cares-make.patch與倉庫現(xiàn)狀一致。構建腳本同步對照上游新版本的目錄結構檢查 _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 的新版本時你就能按照同一套可復現(xiàn)的步驟完成升級并借助git diff與測試套件驗證每一步的改動是否符合預期。贊分享后端【免費下載鏈接】geventCoroutine-based concurrency library for Python項目地址https://gitcode.com/gh_mirrors/ge/gevent點擊查看免費下載相關推薦終極gevent事件循環(huán)指南從入門到精通的libev與libuv實戰(zhàn)選擇終極gevent事件循環(huán)指南從入門到精通的libev與libuv實戰(zhàn)選擇 gevent是一個基于協(xié)程的Python并發(fā)庫提供了高效的事件循環(huán)機制。本文將深入后端gevent 協(xié)程并發(fā)網(wǎng)絡庫完全指南greenlet 與 libev/libuv 事件循環(huán)架構、安裝與實戰(zhàn)gevent 協(xié)程并發(fā)網(wǎng)絡庫完全指南greenlet 與 libev/libuv 事件循環(huán)架構、安裝與實戰(zhàn) gevent 是一個基于協(xié)程coroutine后端gevent 嵌入的 c-ares基于 C 的異步 DNS 解析器解析、安全設計與集成實戰(zhàn)gevent 嵌入的 c ares基于 C 的異步 DNS 解析器解析、安全設計與集成實戰(zhàn) 導讀 本文以 deps/c ares/README.md htt后端上一篇蓄水池抽樣Reservoir Sampling算法詳解流式數(shù)據(jù)等概率隨機選取的原理、證明與實戰(zhàn)下一篇CANN ops-math 算子實戰(zhàn)aclnnFmodTensor 與 aclnnInplaceFmodTensor 張量取余接口全解析創(chuàng)作聲明：本文部分內容由AI輔助生成（AIGC），僅供參考