Re: [問題] multiprocessing 的 Pool.map

[zerof (貓橘毛發呆雕像)]

前文 43

code snippet:
    https://gist.github.com/lanfon72/5ebb60ba261fe9f5cc4bd6ca54480adb

先澄清幾個問題:

  a. 跳下去看了一下 Pool 的 code 順便測了一下 sys.stdout ，發現是應該是沒有
     racing condition 的問題，請忘了這件事....QQ

  b. print 實際上是寫進 sys.stdout 物件(IO)，我沒搞錯的話會在 newline 的時候
     強制 flush 。

  c. sys.stdout 沒有 flush 的時候是存在 sys.stdout 裡面， flush 的時候輸出的
     點是共用的(user screen or file).

  d. subprocess 和 process 是不同的東西...

: → zerof: 不是                                                     04/23 01:20
: → zerof: print 預設的 file = sys.stdout 是共用的, 設 flush=True   04/23 01:49
: → zerof: 可以解決這個 racing condition                            04/23 01:49
: → zps: 請問是否可以想成，print 已執行，但還來不及輸出             04/23 10:45
: → zps: 程式就結束了，所以若有加上 join 會有效                     04/23 10:46
: → zps: 可是為何 print(x) 仍有效呢？                               04/23 10:47

   見 a, b & c，後來發現 sys.stdout 物件不是共用的...QQ

: → s860134: zerof 的意思是指說當有一個以上的行程同時跑到 print     04/23 12:11
: → s860134: 時，會變成序列化的輸入，造成看起來是 blocking          04/23 12:12
: → s860134: 和你有沒有加 join 應該是沒關係~                        04/23 12:13
: → zps: 印出不連續這部分我了解，但我的問題主要是印不到30個就結束   04/23 14:00
: → zps: 理論上，pool.map 應該都要等到 subprocess 跑完才會結束      04/23 14:01
: → zps: 但我實際 run 的結果，有時卻是不到30個就結束了              04/23 14:02
: → zps: 但 print(x) 卻可行，後來試過加上 flush 也是可行的          04/23 14:02
: → s860134: 你可以做一個實驗，每個 process 都印自己的 pid          04/23 20:39
: → s860134: os.getpid() 個人猜測是發生同時寫入相互覆蓋             04/23 20:40
: → zerof: 參考 #1OzP7wJp (Soft_Job)                                04/23 21:21

  實際上它是「結束時沒有被捨棄的輸出」，你可以跑一次上面的 code ，會發現 print
  輸出的順序是 pool.map, print("stdout:"...), 最後才是 processes 要印出來的東
  西。

: 1. 沒印出任何東西
: 2. 4376 4376 4376 (印出三個 pid)
: 3. 5772 5772 (印出二個 pid)
:
: 就我個人的理解，因 print 會先 buffer，之後才會一併顯示在螢幕上
: 2 & 3 應該是相互覆蓋所造成的，但若是相互覆蓋造成的
: 理論上改為以下的 code 應該也是同樣的情況，加上 close() & join()
:
: 卻可以正常顯示五個 pid，這裡跟我前面的推論矛盾了
: 而 1 的部分，完全沒印出東西，也是我覺得納悶的地方

  在沒有 pool.close() & pool.join() 的情況下， Pool spawn 過的 Processes 實際
  上會在 mainThread 結束的時候執行 terminate ，這也是為什麼  print 在沒有使用
  flush=True 的輸出會在最後的原因。

  Pool 並沒有用 atexit.register 去清那些會在 interpreter terminate 被強制終止
  然後回收的資料，所以 1. , 2. & 3. 的情況都是正常的。


  簡單來說:

  1) 沒有被 flush 的資料會被暫存在 sys.stdout object 內
  2) Process 會在正常 exit 的時候把 sys.stdout 裡面的東西 flush 掉
  3) interpreter terminate 的時候不保證資料完整性

  你可以試著把上面的 code 第 22 行 uncomment 之後跑看看就會知道我在說什麼了...
  ((總之忘了 racing condition 吧真是太誤會了QQ
  ((難怪我測了兩種 Lock 都沒用果然是走錯路...

--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 122.100.76.218
※ 文章網址: https://www.ptt.cc/bbs/Python/M.1493052706.A.C43.html
→ zerof: 感恩這問題讓我領 500.......順便又上了一課QQ
推 zps: 感謝Orz，所以不同的 process 可能會有不同的 sys.stdout
→ zps: 然後 terminate 時，會隨機挑選其中之一進行 print
→ zps: 因為 uncomment 22行後，會看到三種結果都出現
→ zps: 但若是有加上 close() & join() 則會全部清出
→ zps: 請問我可以這樣理解嗎？
→ zerof: 用 close() & join() 是確保 Processes 會正常結束，所以在
→ zerof: sys.stdout 裡面的資料會被 flush
→ zerof: interpreter terminate 的時候急著下莊所以不會等 Process
→ zerof: 正常終止
推 zps: 所以運氣好的 process 會在下莊前印出東西
→ zps: 有時甚至沒有 process 趕上下莊前，就結束了，所以沒東西印出
→ zps: 改一下說法，運氣好的下莊前可以正常結束，所以會 flush
→ zps: 感謝您的詳細說明
推 s860134: 很有趣! 剛測了一下，真的只要不 print 到 \n
→ s860134: 就完全不會去清子行程的 stdout，在主行程結束才去清QQ