※ 引述《zerof (猫橘毛发呆雕像)》之铭言： : : 我也可以用 multi-process 而不是 thread 来解啊 : : 解法不只一种，而且我不认为问题出在 GIL : : 毕竟我的 thread 有三十多个，我也真嫌多了 : : 用了 Coroutine 就合并回一个，但却是三十多个 task : : 我觉得这也蛮好的 : : Coroutine 既然是个潮流就来了解一下，有别的解法就先放一边吧.. : : 真要 C 我何不回 C 的世界，写纯 C.. : 你要不要看看 Chrome 开起来的时候平常是起几个 Threads ? 在你这篇文前我就想过这个问题了 可是这个比较并不公平 你基於 chrome 跑起来流畅，偷渡了 python 即使只写 single thread 执行速度都输给 c 的事实 一个是 compile 语言，一个是 script 是否 chrome 也用 python 写，但用上 pypy 取消 gil 的影响再来比？ 还有，我的 python 程式在 Mac 上开发，也感觉很流畅啊 是传到 RPI 上才跑得有点慢的 chrome 有很快吗？浏览器在 RPI 上，感觉也慢不少啊 电脑等级不一样也摆在一起比？ 有一件事我没在前面的文章中提及，就是 multi-thread 在 debug 时给我的困扰 我用中断点暂停了一个 thread, 但其他 29 个 thread 还在跑 这导致大家共用的变数飞快的改变着，我很难单步执行 （但的确又有一些 thread 在背景还能跑也给了我方便） 而 Coroutine 它们事实上是同一个 thread 这件事让我可以在中断一个 task 时，其他 task 都停下来 这是我要的；之前没 Coroutine 我也渐渐在安排这种架构 比如我有十个 sensor, 本来各跑一个 thread，後来串起来在同一个 thread 跑 比如本来一秒读一次，我就一秒启动一个新的 timer thread 结果我中断在某个 sensor read 时， 还每一秒都有一个新的 read request 闯进来，不堪其扰了 所以虽然读 sensor 是飞快的事，一秒内一定能读完，可以一秒启动一个 timer thread 我还是只启动一个 thread 并且写成 while loop 这样只要读取没完成，就不会有新的 read request 可以说 free run 并没有问题，是 debug 时出一堆问题 就我看目前我的程式都不要改，卡的情况老板也能接受 不接受的是我，因为只要 debug, 程式就卡得不能动 当然短期内我不用单步执行，狂加 log 也解了不少问题 : Coroutine 是潮流? 你不是写 C 吗怎麽没用过 libtask ? 真没用过 : 这也难怪前面被呛先回去读 OS ， Preemptive/Cooperative multitasking 是不是 : 都没听过 ? 这就有听过了，写过 windows sdk, message loop 就类似协程的一种 guizero，或者说一堆 GUI framework, 都用 callback 或 event driven 运作 就算这名词没听过，也许我已经在写这种程式了 所以其实我本来想自己打造 Coroutine 的 就我看，task 其实都是在同一个 thread 跑 但是有一个 framework 巧妙的把它转换成 message loop 的型式 只要目前执行中的 task 阻塞，就跳转另一个 task 跑 : 如果问题不是出在 GIL ，那问题是出在你的 code 架构不对？ 如果我对 Coroutine 的理解没错，也就是它只是帮我实现我想要的架构 我完全可以不用 Coroutine，但又只用一个 thread 写出来 所以，是的：我的 code 架构不对 我常说的一件事：如果写一个射击电玩，画面上有五十架敌机 哪有必要用 50 个 thread 去写？当然一个 thread 运作五十架敌机没有问题 但因为我在安排架构上出了问题，所以才改用 thread 写 在 thread 内我可以专注在运算一架飞机 写着写着想要 sleep 就sleep, 不用担心其他飞机被暂停了；反正它们在其他 thread 看在事实上只有一颗 CPU，只有一个核心的份上 我认为所有的 multi-thread 其实都可以写成 single thread 用上 multi-thread 不就是因为思维可以清晰，有底层硬体支援 所以我的逻辑概念可以抛掉一些事由 OS 负责吗？ Coroutine 也给我这种感觉 现在我可以想 sleep 就 sleep, 控制权会交给其他 task 而我的程式语法还是单纯 我本来要自己硬干的，若我干出来了，我就会说那个架构好，而现在这个架构差 方法就是打造自己的 message loop，把一份工作切成许多程序薄片 每一个薄片做完就切换到另一个薄片，每个薄片间没有 multi-thread 会发生的交链 这样就算没 GIL，我也是自己手工打造了一样的副作用 所以我不会抱怨 GIL : 我确实是蛮好奇的啦，如果你可以断定不是出在 GIL ，难道 PyQT 的 QThread 是写 : 来好看的？ 话不能这麽说，常说的一句话：问题有很多解法 别人依赖我不依赖啊.. PyQT 把这架构，打造给依赖它的人 (区块变色好难，好像只变到一行？) : 我想你从头到尾没有搞清楚 GIL 所以根本不明白 GUI 为什麽会 freezing : threading 本身就是 preemptive 的， GIL threads 在 context switching 的时候 : 会有 Locking 的问题，反过来说， GUI 要执行的 main thread 无法保证总是抢得到 : GIL ，而产生 freeze 的现象；当你 threads 开得多，里面又都是跑 python code : 的时候就会非常的明显。 : Python 连 serial/smbus 的 libraries 都是 blocking I/O ，最底层摸到 sockets : 的时候的确是会 release GIL ，但回过头来就还是 preemptive 的本质：你没办法保 : 证 GUI 用的 thread 一定会抢到 GIL 。 这些我知道 : 这问题换到用 asyncio 并不会被解决，本质上的差别。 asycnio 底层用的 sockets : 是 non-blocking 的，你用同样的 libraries 来跑，一样会遇到 GIL 的问题，而且 : 更严重。(GUI 一个 loop, asyncio 一个 loop) 用 29 个 working thread 和一个 ui/main thread 来说 我目前的架构是 free run 时，每个 thread 占用三十分之一的 process 效率 UI 必需和大家共享，那也才三十分之一, 3% 但我不很在乎我的 working thread, 愿意合并成一个 thread，内含 29 个 task 於是 main thread 变成 二分之一，50% 的效率 （而我不清楚 main thread 会不会加重，开出的其他 thread 不与它平分 但若加重也是这两个比较的 main thread 都加重） 当然事实上可能不是大家都 free run 写 multithread 时 free run 会很恐怖吧？我都会加 sleep 而根据 sleep 的时间，如果某 thread sleep 特长，长到夺得控制权的机率并非平均 上述算式就差更多；但基本上我狠狠的加大 working thread 的 sleep 时间并不是问题 : loop.run_in_executor 的本质是 concurrent.futures 底下的 ThreadPoolExecutor : ，当然你也可以改用 ProcessPoolExecutor ，这跟你原本的 threads 改成 Process : 一样，唯一的差别是 Executor 用的是 Worker model。 : 回过头来说，照你原本 30 threads 的版本，可以先试着用 pypy 跑看看能不能加速 : Python code 执行的速度，减轻 GIL 的影响 (没错， pypy 也是有 GIL)；另外的选 : 项用 Cython 把 threads 用 release_gil 加速。 : 上面两个选项都是最小改动，要完全避免 GUI freezing 的话就是把 threads 移到 : 另一个 Process，变成 Thread(GUI) <-> Process (Threads) 的架构，但如果你在 : 各个 threads 之间有 sharing data ， IPC 的成本不见得会比较低。 1. 取消 GIL 後，我的程式就要面临 thread safe 的挑战；目前都没安排 GIL 为什麽被采用？当我写了一阵子 python 後我发觉，它不像 C 是要高效的 它释放我的脑袋在处理逻辑上，当我紧张的写一小段程式，要看它会不会当机时 C 的写法会在 thread 里撞变数，一定要 critical section 而 python 的写法不会，可以说 python 的 ATOM 就是很大颗，蛮横但好用 2. 切成两个 Process 是我前面也谈过的架构, IPC 是一定要的，比如跨网路 由远端网页连入近端，那麽近端只要运作所有 working thread，根本不用 GUI 这部份完成了啊，我的 UI 不让 working thread 直接取值的 UI 只写入 MySQL, working thread 只从 MySQL 取资料就开始跑 所以我只要运作起 MySQL, 它就替我做完我要的 IPC 了... 开放网路连入 MySQL server，就变远端控制.. 来说说 GIL 我看到的经典差别是什麽 以两轴马达控制器来说，C 写的可以完美的走一条斜线 而 python 写的，则是会抖动的走一条斜线；要嘛走 x 轴，要嘛走 y 轴 就是不同时走 当然用点技巧解掉就不会了，总是得刻意用最简单的写法来强调 GIL 的影响 我这段反白，和你上面那段红色的，差别是一个用专有名词，一个用口语描述 如果你说我这样叫做不懂，那差别在哪里？ （差别在 google 搜寻方案时，有专有名词比较精准；当然这是好事） 不过我还要说一个我面临的问题，不是 GIL 的影响 而是 GUI framework 一般来说，有一个 'render' 的时间 如果我让程式进入一个自己的 while loop 永远跑不完 在 working thread 是没问题的，但在 UI thread 它就是不绘图 可以说我的绘图指令，或者摆放各个 UI 控制项的指令 都只像在安排结构，而这个结构必需等 ui thread 有空时才会被 guizero 解析并绘图 因此绘图的反应要快，那每个 callback 就要快点执行完且 return 回 main loop 如果执行快但很快又要执行新的 callback, 留给 framework 的 idle time 不够长 它就是不绘图；症状是我可以用 print 或 log 看到，指令都有执行完但它就是不绘 如果在 windows os, 我会下一道 update window 相对其他类似的 framework，我也都在找这道 update window 指令 要嘛没找到，要嘛我觉得快点执行完返回 main loop 也不错，我已经习惯了 GIL 不只要抢到，还要 idle 够久，否则不只是卡，是画面根本不出来！ : 当然你也可以写 C 啦，能用的东西多得是，会不会而已。 : BTW ， asyncio 真的不好吗？当然不是。但 Python 的 async 有传染性，而且受限於 : GIL ，sync -> async 不实际， async -> sync 更是自找麻烦。 : 糯米掺黏米又怎麽会好呢？ 要写 GUI 不如左转 nodejs 吧 你提 nodejs 就更可以狠狠的骂我了 不会，完全不会 XD 当年写 C 时，我是计较千分之一秒的人 现在写 python，为什麽不坚持 C？ 因为一开始专案评估时，老板就对我说： 我们的 sensor, relay, 你一分钟运算一次就好 我一听，这根本是杀鸡用牛刀，python 慢归慢，够用；来学一下 XD 所以比如切两个 process 可解，我为何要用 Coroutine 解？ 因为它有趣，我要求不高，还可以解 事实上现在我还是写成 sensor/relay 一秒运算一次 因为如果一分钟运算一次，我在 debug 时也等得累了 http://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/ 传染性是指这件事吗？ 我想这就是大力向我推荐 Coroutine 的朋友该替我想一下的了 当然我知道大家都不是各领域的业务，只是兴趣 他喜欢 Coroutine，想让我试试 Coroutine 那我试了，碰到问题并回报 如果他不帮我解决这问题，那我以後就不会再考虑 Coroutine 难道大家要接受 Coroutine 是个鸡肋这想法？ 既然说出要安排个好的架构（但好的架构就是排除 Coroutine?） 好啊，那这就是个题目 如果我成功的切成两大块，那就不会有很多的混 call 两大块间用 async/sync queue 连来连去 就好像程式内的 IPC，这是 async 和 sync 里的 IPC 那我就真的能用它解决一些问题 而那些问题我未必有描述在文章里，所以你不知道我有这些要面对 --

※ 发信站: 批踢踢实业坊(ptt.cc), 来自: 1.168.18.180 (台湾) ※ 文章网址: https://webptt.com/cn.aspx?n=bbs/Python/M.1675837098.A.C3C.html 他的文我一开始也没看懂，後来才发现都我知道的概念 只是我没用那些字眼 即使都是中文，语境也是要吸收的 ※ 编辑: HuangJC (1.168.18.180 台湾), 02/08/2023 15:58:34 可是他的文我也觉得讲到我本来就懂的部份啊 是他以为我不懂。。 那就真的解掉问题吗？ 举 chrome 为例子，那又不是没 GIL 版本的 python 这样做比较，似是而非吧.. 偷渡了论点你能比较出来吗？ 在做物理实验时，观测变数必需独立 而不是利用改善变数 A，去证实改善变数 B 有效吧？ 就好像台湾近年来愈来愈差 於是有人说：二十年前还有联考，改回联考台湾就能重返荣耀 是这样证明的吗？ 怎麽不说时代变了，从前的教育也会不适用 多变数能这样观测及证明？ 但是普设大学很多人说不好，改回联考的论点也让人秒懂 让你秒懂的东西就是对的？ 我上次说我 C 的底子十年对吧.. 好吧，我比你资深，没错 但我也说了，这时膨风没有好处 反而只会被电：都这麽资深了这个还不会 谢谢，因为我英文很烂 XD；等等修 那你也看看介绍给我的网友怎麽说的 coroutine 的代价比 multi-thread 低... 光论逻辑其实都是把程式切薄片 但实作方法就有差别，也就是这个差别造成它的代价低 那现在你要怎麽给评估建议？ '凡是不能写成纯 Coroutine 的，就不建议用 Coroutine'? 倒也不是，前面有板友给我解了，有本事 thread 和 task 混在一起 你也说了，使用 UI framework, 有 callback 是常态 我以为这句的语气不应是对我，应该是对别人 因为我本来就知道是常态，我一直说我要走通 sync call async 这条路，无法回避 是别人说我为何把问题搞得这麽复杂 那这时接你这句'使用 UI framework, 有 callback 是常态'不是很能替我说话吗？ 这是我无法避免的挑战，不是我把问题搞复杂 先不说切成两个 process 的解法 我自己就有提出，你也提了一次，这没什麽争议的 如果你附议'当有 UI 时还写 coroutine 是自找麻烦' 那这件事就落幕了，当初我说我想自己分配 CPU 时间，网友的建议... 因为他们不知道我有 UI 要写，所以不能说建议错 但如果先知道我有 UI，有 sync callback 是否他们根本就不做此建议？ 我知道大家只是建议，我自己的工作是自己的责任 只是现在别管怎麽写了，连'评估'都成为一道题目 所以大家要附议这句吗：当有 UI framework 时，用 coroutine 是自找麻烦，不值得 （因为我真的可以用两个 process 写，而且也铺陈很久了） 》果然回文是浪费时间 你的态度认为你是对的，是来教训我而我不受教 所以才会得到浪费时间的结论 那就请你不要回文了，因为如你说的，我自己可以去看那薄薄的文件 我还没给你钱呢.. 算一下你的时薪，如果要聘你当顾问，我一定出不起 我以为这里是讨论的地方，不是教训的地方 我之所以不敢亮出自己真实年资，是因为我的实力根本不能彰显年资 要教训别人谈不上，都是来讨论的 我的理解是这样的 比如一个 thread 说 a = 0102030405060708h (简单的八个 byte 长度变数) 用硬体触发 CPU 中断，则很可能在 a = 01020304h (前四个 byte) 已经存入变数位置时，失去 thread 控制权 （当然这看 compiler 怎麽实作，通常一道机械指令就搬完八个 byte，就不会发生这事 我要讨论这个时必需假设实作了一个很烂的 compiler） 但下次 thread 取回控制权时，还得接着存入後面四个 byte,也就是 05060708h 为什麽会知道从这里继续存？这就是 context switch 保留了一切的缘故 其中包含了所有的暂存器 就逻辑概念来说，除了 thread 失去控制权几微秒，其他事一如往常 所以这个 thread 可以无痛的继续跑下去 既然这麽无痛，那任何时间切都可以，用的是时间中断 python 的就不是了，比如一次执行一百道 python 指令 所以我说 python 的原子又大又蛮横，变数 a 的 8个 byte 我是没在担心被拆开的 以这样的程式（虚拟码）来说 thread1 = while True print('t1 looping') thread2 = while True print('t2 looping') 在 multi-thread 可以正常跑 但在 multk-task，就会出事了 task1 = while True print('t1 looping') task2 = while True print('t2 looping') 因为若 task1 先执行，它就会 hold 住控制权，再也不释出 至少也得在里面摆个 asyncio.sleep(0) 那这道指令其实就是切程式薄片的位置 它不是时间引发中断 》更需要理解 time sliding 它是由工程师自己用 code 决定要在哪里保留机会切换控制权 我得去协调这些，但如果我有需求，我可以让切换很少发生；够用就好 比如我说我们专案是一分钟执行一次就好 那我放心给每一个 thread 执行两秒钟 三十个 thread 都要轮到，轮一次就一分钟 这也是可以的 不过呢，我的程式不快，相反的是很慢 比如某个动作一做就是这样 开窗户 = relay On sleep(七分钟) relay Off 我要安排的是高达七分钟的工作 XD 看来看去 Coroutine 很方便，直接塞三行指令完成 如果自己做又不想塞住，那我只好把工作排上时间，丢进 message queue 里去了 这像你说的要了解更多 time slide? 我所看到的文件是说，要了解 message loop 而且我是从 windows sdk, windows MFC framework 一路学上来的人 接触了微软那套 message loop 很久，的确有熟悉的感觉 比如使用者按了键盘，就有 onKey event, 滑了滑鼠，有 onMouseMove event 如果我 onKey 处理十秒，那滑鼠也会有被卡住十秒的感觉 onkey 就是得快快处理完 那麽这套 framework 就能让 user 感觉键盘和滑鼠两件事，像多工一样 但它们事实上不是 timer 中断直接触发 CPU 引起全部暂存器的本文切换 而是一段段完全不会同时执行的 event driven 程式片段 我这段理解，有误吗？ 》复杂度问题才会很多程式都还是用 multi threads 好啊，不谈怎麽写，只谈决策 所以 Coroutine 到底为什麽要发明出来？ 1。不好学 2。学了，也不好用 如果你是对的，那你就是在教训别人，当然你觉得是浪费时间 如果有任何一位大德跳出来说'其实很好用，就算是 UI framework 也很好用' 那这就是讨论了，相信对你也就不算浪费时间了 》但 C 语言我有十年以上的底子 我不想亮出年资啊，我超过二十五年 这麽说吧，你没看到我说我写过 windows sdk 吗？ 从 win 3.0 开始开发 app，那年资多少？ 那时要自己写 message loop, 没有 MFC framework 用的是 C 而不是 C++ compiler 是 Microsoft C 而不是 Visual C 可是年资愈久却没跟上，不是被笑得更多？ 事实上我不可能没听过 Preemptive/Cooperative multitasking windows sdk 一开始写 message loop 就在讲这个了 但既然有人要用教训的语气抖出这句 那好，就谦虚点，看他能讲出什麽来 怕的就是我挂万漏一，有什麽没学好的，赶忙补充一下 比如 libtask，我还真没用过 学习讨论不是用这种态度的，不会就学就是了 如果非要用两个 process的做法，我已经有解了 我只是想尝试另一种做法 你不会，不代表别人不会 要嘛要混，就不建议用 Coroutine 要嘛仍然建议用，那就会有解 比如那个贯穿 sync/async 的 queue 就是很好的解法 而且我已经说过你的语气有问题了，我早说我需要这种 callback 所以你在酸的是我，还是不知道有这种 callback 需求的其他网友？ 非要在我身上发作 开头就说笑死，是该有的讨论态度吗？ 有 sleep 才好啊，代表我的速度要求其实不是很高 高达七分钟的 sleep, 所以我才做这种规划 我们用的是低速马达，或说有减速齿轮 天窗的开关就是七分钟或十分钟这种大单位 事实上目前我把 Coroutine 当成实验在学习 专案分裂成两个 branch，以免 Coroutine 没写好却毁掉专案 另一个 branch 仍然维持用 multi-thread 写 也因为专案的速度要求不高，程式还是跑得动 我说过，老板要求一分钟判断条件一次，我还是做一秒钟判断一次 我的余裕是很足够的 可是後来有一天，老板提出一秒钟的需求 （也就是常见的，客户并不了解自己需求，我们必需有充份的准备） 所以多的其他学习，我都是在为未来的挑战先准备而已 ※ 编辑: HuangJC (116.241.233.114 台湾), 02/16/2023 00:31:58 我整理一下我的文字好了：我不能 release GIL 因为我早就习惯 GIL 的存在 如果直接 release GIL，我也要改写不少程式 包括重测试所有 thread safe 的问题 你觉得 release GIL 是个解 而我的程式 release GIL 就先有 BUG 了 GIL 当初被发明出来，是因为去除不掉所以才留着的吗？ 而现在要去除，是因为技术进步了吗？ 我倒觉得那是个有趣的 spec, 也让写程式变简单了 因为事实上不会有两个 thread 同时执行 所以 thread safe 的问题就变简单了 我的程式早就写成依赖 GIL 了 因此这不会是我的选项 知识不会因为资深就自然拥有 我的意思不是学得久 我的意思是，win 3.0 sdk 学起，这时就已接接触到 message loop Preemptive/Cooperative multitasking 这时已经学到了 我所说的细节也涵盖了这些 因此，他说的我听得懂，至於我说的你听不懂，但有时那也是关键 有些地方会有似是而非，秒懂可能是秒误解，必需分辨一下 所谓的谦虚，就是你说我不懂，那我就等看你懂的有没有我遗漏的 但我不会是'完全都不懂'好嘛 难道我也要用一样的语气，只要抓到你一点点错误 就说笑死，就说你完全都不懂？ 所以你其实是不敢吐槽对我做出建议的网友，指桑骂槐，你要骂的是他们吧！ XD 我算是搞懂了 要知道我本来就是来请教的，我不懂是刚好而已 我又不是打着'我是 Coroutine 专家，有不懂的我来教你'这种招牌出现的 我一直说的是我不熟，我不会，我第一次学 Coroutine 结果你把我损成这样 你是不是只敢骂我，不敢骂建议的其他人，所以非要发作在我身上啊？ 厘清你的情绪好嘛！ 》那麽，async -> sync 要怎麽不 lock event loop 呢？ 这是我问的问题，不是我提出答案好嘛 有人说我架构不好，为什麽非要有这种东西 我则一直提出各种例子（因为一开始我不想抖出 guizero）说我就是有这需要 你是不是爬文时看不懂谁发问，谁摆架子啊？ 发问的是我好嘛 因此那个说我架构不好的人，才是你该酸的 你可以酸他：这不是架构不好，这是一定要面对的挑战 你要酸对人啊！ 都有人回 async <-> sync 的 queue 了（双向喔！） 如果非要用 queue 包成 lock，code 会长得有点难看但也不是做不到 而如果也有 async <=> sync 的 lock 就更好了 你只要说我半桶水，我就会自我检讨自己是不是没学完整 multi-thread 我也学十几年了，被你说完全不懂 那你就是完全懂罗？绝对不是五十步笑百步？ 那你还解不了这问题？ 年资没什麽好说嘴的，所以我一开始没抖出来啊 谢谢，看来得再检查一下文章 是的，就是那多一点的掌控权迷人 本来我要自己做的，在没有 await 工具时，自己切割程式薄片 看到这工具真的觉得是了不起的语法糖 因为我自己就会切程式薄片 所以我也尽我所能的在理解 await 是怎样的东西。。 以我的程式来说，await 应该不会很频繁 因为我希望所有的 working thread 合并成一个 那就是 30 个 task 切来切去 若频繁，我会加长它们的 sleep 因为一个硬体动作可能就有七分钟的 sleep 所以非常有余裕 ※ 编辑: HuangJC (116.241.233.114 台湾), 03/04/2023 03:04:41 > Python 连 serial/smbus 的 libraries 都是 blocking I/O ，最底层摸到 sockets > 的时候的确是会 release GIL ，但回过头来就还是 preemptive 的本质：你没办法保 > 证 GUI 用的 thread 一定会抢到 GIL 。 > 这问题换到用 asyncio 并不会被解决，本质上的差别。 asycnio 底层用的 sockets > 是 non-blocking 的，你用同样的 libraries 来跑，一样会遇到 GIL 的问题，而且 > 更严重。(GUI 一个 loop, asyncio 一个 loop) 来看这段，我不懂这有什麽问题 我的问题是：我不知道有没有误解什麽是 socket 是 python 任何 Coroutine/thread 动作，都基於网路，基於 IPC，基於 TCP/IP 或者说，你的 socket 就是指硬体动作，如果我不做硬体动作，就不会动到 socket? 如果是後者，那就没问题了 我说过，我的程式可以完全切开，硬体不去碰 UI，不混在一起 同样的，我 30个 working thread 在用硬体 如果它们合成一个 Coroutine thread，那这个架构就是只有一个 thread 在用 socket 你不知道我的规划，不能把你会遇到的问题，以为我也会遇到吧.. 当 mainthread 从占用效率三十分之一，变成占用二分之一时 它也会更顺啊，至於是你说的对，还是我说的对 关键在程式的架构，而不是 Coroutine 绝对不行吧！ 不然你就大声说，当有 UI 时，不建议 Coroutine (也不能说任何 UI，你有建议别的 那我们限缩范围，当我要用 guizero 当 UI 时） 好啊，你的建议我听到了 （其实你也不用覆述，除非你要怪我脑补，不然你不断重覆的就这个意思） 我是来请教的，你是来给建议的；比较奇怪的是我就是不懂才来找建议的 为什麽你可以酸成那样？ 你真的要厘清你的情绪 因为我是来请教的，所以你说我不懂，我就不懂好了 但不会'完全不懂'好嘛。。 行百里半九十，就算我懂九成，也还是不够懂 当然是这样啊 ※ 编辑: HuangJC (116.241.233.114 台湾), 03/31/2023 12:04:35