› 看板 Python 關於我們 聯絡資訊
作者HuangJC (吹笛牧童)
看板Python
標題Re: [問題] 請問 Coroutine & 一般 callback 合作的問題
時間Wed Feb 8 14:18:15 2023
※ 引述《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://www.ptt.cc/bbs/Python/M.1675837098.A.C3C.html
推 celestialgod: 我不知道有沒有人看得懂 我看不懂 02/08 15:46
他的文我一開始也沒看懂，後來才發現都我知道的概念 只是我沒用那些字眼 即使都是中文，語境也是要吸收的 ※ 編輯: HuangJC (1.168.18.180 臺灣), 02/08/2023 15:58:34
→ leolarrel: 我也看不懂... 02/08 16:28
→ leolarrel: 我C寫了25年,看不懂他在說啥.一定是我還不構資深 02/08 16:28
→ leolarrel: 反而zerof 的文我秒懂... 02/08 16:30
可是他的文我也覺得講到我本來就懂的部份啊 是他以為我不懂。。 那就真的解掉問題嗎？ 舉 chrome 為例子，那又不是沒 GIL 版本的 python 這樣做比較，似是而非吧.. 偷渡了論點你能比較出來嗎？ 在做物理實驗時，觀測變數必需獨立 而不是利用改善變數 A，去證實改善變數 B 有效吧？ 就好像台灣近年來愈來愈差 於是有人說：二十年前還有聯考，改回聯考台灣就能重返榮耀 是這樣證明的嗎？ 怎麼不說時代變了，從前的教育也會不適用 多變數能這樣觀測及證明？ 但是普設大學很多人說不好，改回聯考的論點也讓人秒懂 讓你秒懂的東西就是對的？
→ leolarrel: 反應怎麼那麼激動,我只是說他的內容我看了秒懂.你的我 02/08 17:30
→ leolarrel: 看了三遍還是不懂.所以我說我還不構資深阿 02/08 17:30
我上次說我 C 的底子十年對吧.. 好吧，我比你資深，沒錯 但我也說了，這時膨風沒有好處 反而只會被電：都這麼資深了這個還不會
→ aalexx: framework是一個字 02/08 17:53
謝謝，因為我英文很爛 XD；等等修
→ zerof: 我的頭好痛 果然回文是浪費時間… 我只想到葵花寶典第一頁 02/08 21:26
→ zerof: 你肯定是沒切就開始練 02/08 21:26
→ zerof: multi thread 都沒練好就跑去練 coroutine 我的媽咪啊... 02/08 21:26
那你也看看介紹給我的網友怎麼說的 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 寫，而且也鋪陳很久了） 》果然回文是浪費時間 你的態度認為你是對的，是來教訓我而我不受教 所以才會得到浪費時間的結論 那就請你不要回文了，因為如你說的，我自己可以去看那薄薄的文件 我還沒給你錢呢.. 算一下你的時薪，如果要聘你當顧問，我一定出不起 我以為這裡是討論的地方，不是教訓的地方 我之所以不敢亮出自己真實年資，是因為我的實力根本不能彰顯年資 要教訓別人談不上，都是來討論的
→ zerof: GIL 的 paper 也才幾頁 看一下不需要太多時間 用 asyncio ( 02/08 21:35
→ zerof: coroutine) 比 threading 更需要理解 time sliding ，更何 02/08 21:35
→ zerof: 況 python 的 coroutine model 是 single thread event loo 02/08 21:35
→ zerof: p ; 複雜度問題才會很多程式都還是用 multi threads 02/08 21:35
→ zerof: 其他我就不說了 background knowledge 不夠 說了也是白搭 02/08 21:36
→ zerof: 省點彼此的時間 我當看戲的 02/08 21:36
我的理解是這樣的 比如一個 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 也很好用' 那這就是討論了，相信對你也就不算浪費時間了
→ leolarrel: 十年比二十五年資深...... (其他的我沒意見 02/09 10:38
→ leolarrel: 算了我也跟zerof 一樣看戲好了 02/09 10:42
》但 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，我還真沒用過 學習討論不是用這種態度的，不會就學就是了
→ s860134: 不要浪費時間 半瓶水 02/09 18:18
如果非要用兩個 process的做法，我已經有解了 我只是想嘗試另一種做法
→ zerof: 笑死 XD 你先想想 async model 的 coroutine 怎麼接會 sync 02/10 00:20
→ zerof: function 的 callback 吧 走火入魔 幫不了你 02/10 00:20
你不會，不代表別人不會 要嘛要混，就不建議用 Coroutine 要嘛仍然建議用，那就會有解 比如那個貫穿 sync/async 的 queue 就是很好的解法 而且我已經說過你的語氣有問題了，我早說我需要這種 callback 所以你在酸的是我，還是不知道有這種 callback 需求的其他網友？ 非要在我身上發作 開頭就說笑死，是該有的討論態度嗎？
推 Yshuan: 一直看到sleep... 就不想認真看了(? 02/13 11:03
有 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 了 因此這不會是我的選項
→ leolarrel: 喔,寫過windows 3.0的sdk ... 02/16 10:22
知識不會因為資深就自然擁有 我的意思不是學得久 我的意思是，win 3.0 sdk 學起，這時就已接接觸到 message loop Preemptive/Cooperative multitasking 這時已經學到了 我所說的細節也涵蓋了這些 因此，他說的我聽得懂，至於我說的你聽不懂，但有時那也是關鍵 有些地方會有似是而非，秒懂可能是秒誤解，必需分辨一下
→ zerof: 你從頭到尾都沒有理解問題啊 guizero 用的 callback 不是 a 02/16 12:17
所謂的謙虛，就是你說我不懂，那我就等看你懂的有沒有我遺漏的 但我不會是'完全都不懂'好嘛 難道我也要用一樣的語氣，只要抓到你一點點錯誤 就說笑死，就說你完全都不懂？
→ zerof: sync loop, 你要用 async 只能把 event loop 開在另一個 th 02/16 12:17
→ zerof: read 裡面，那麼，async -> sync 要怎麼不 lock event loop 02/16 12:17
→ zerof: 呢 ^^ 02/16 12:17
→ zerof: 直接點說， async 沒有不好，問題在於 Python 的 async mod 02/16 15:30
→ zerof: el 沒有表面上單純，不然從 3.4 包進 builtin 之後早就變 02/16 15:30
→ zerof: 熱門話題了(看看隔壁的 go, js) 你如果連 Python 的 genera 02/16 15:30
→ zerof: tor, GIL 都不熟，用 async 只是搬石頭砸自己的腳 02/16 15:30
所以你其實是不敢吐槽對我做出建議的網友，指桑罵槐，你要罵的是他們吧！ XD 我算是搞懂了 要知道我本來就是來請教的，我不懂是剛好而已 我又不是打著'我是 Coroutine 專家，有不懂的我來教你'這種招牌出現的 我一直說的是我不熟，我不會，我第一次學 Coroutine 結果你把我損成這樣 你是不是只敢罵我，不敢罵建議的其他人，所以非要發作在我身上啊？ 厘清你的情緒好嘛！ 》那麼，async -> sync 要怎麼不 lock event loop 呢？ 這是我問的問題，不是我提出答案好嘛 有人說我架構不好，為什麼非要有這種東西 我則一直提出各種例子（因為一開始我不想抖出 guizero）說我就是有這需要 你是不是爬文時看不懂誰發問，誰擺架子啊？ 發問的是我好嘛 因此那個說我架構不好的人，才是你該酸的 你可以酸他：這不是架構不好，這是一定要面對的挑戰 你要酸對人啊！ 都有人回 async <-> sync 的 queue 了（雙向喔！） 如果非要用 queue 包成 lock，code 會長得有點難看但也不是做不到 而如果也有 async <=> sync 的 lock 就更好了
→ zerof: Btw, 年資沒有什麼好說嘴的，知識不是你坐在那邊幾年就會跑 02/16 15:31
→ zerof: 進腦袋裡 不如多把關鍵字研究清楚 02/16 15:31
你只要說我半桶水，我就會自我檢討自己是不是沒學完整 multi-thread 我也學十幾年了，被你說完全不懂 那你就是完全懂囉？絕對不是五十步笑百步？ 那你還解不了這問題？ 年資沒什麼好說嘴的，所以我一開始沒抖出來啊
推 Sunal: 通常會用 callback not call back 02/16 18:15
謝謝，看來得再檢查一下文章
推 poototo: GIL會在任意兩行bytecode指令間暫停thread 02/16 21:57
→ poototo: 但協程只在await暫停，比thread較多掌控權 02/16 22:00
推 poototo: 只是await很頻繁，兩個task仍可能data race 02/16 22:05
是的，就是那多一點的掌控權迷人 本來我要自己做的，在沒有 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