推 yinxuanh: 推 03/27 12:39
→ uranusjr: 你跑個 for 迴圈裡面用 async 根本沒意義啊... 03/27 12:42
→ uranusjr: 啊沒事我看錯惹, 實際做事在 asyncio.wait 03/27 12:43
這疑慮是對的， L:48 的 for-loop 的確會導致 L:54 接近循序執行，在 scheduler
沒滿的情況下的確會比較慢。
這部份的考量主要在於 L:54 request 的是主網站而非圖床，避免大量 requests 導致
其他使用者的延遲。
L:64 則是大量 requests 會導致 WinSock 炸掉.... http://imgur.com/zA94lRJ ，只
好加個 limit 再用 wait() 來跑 。 (它炸太快我也不知道上限到底是多少....)
這裡一樣的問題是 async.wait() 會 block 到所有的 task done 才跑下一輪，在某種
意義上 scheduler 也是沒有滿的狀態。
PR welcome.
※ 編輯: zerof (192.19.253.250), 03/27/2017 13:26:18
→ s860134: 其實這個例子比較好用 threading 就好，之前 pyCon 有講 03/27 21:07
→ s860134: 說 requests 在做檔案 IO 時好像放掉 GIL? 03/27 21:07
這蠻有趣的XD， requests 下層的 library 是用 urllib3 是 native python 寫的，
相依性是零，有 connectionpool ，沒猜錯的話是用 threading pool 。
而實際上 GIL 在呼叫用 C 寫的函式的時候都會被釋放，所以在用 open 開檔案的時
候是一定會釋放 GIL 的。
就算是這樣， asyncio 實際上還是比 multithread 快，可以參考這個影片：
https://youtu.be/M8Z65tAl5l4