Bug #14727: TestQueue#test_queue_with_trap always timeout on Windows10

• Status: Assigned
• Assignee: ko1 (Koichi Sasada)
• Target version: -
• ruby -v: ruby -v: ruby 2.6.0dev (2018-05-01 trunk 63310) [x64-mswin64_140]
• Backport: 2.3: UNKNOWN, 2.4: UNKNOWN, 2.5: UNKNOWN
• Tags: thread, win

[usa (Usaku NAKAMURA)]

表題の通りです。ささださんも把握しているそうなので、備忘録として。

[19/35] TestQueue#test_queue_with_trap = 10.13 s
  1) Error:
TestQueue#test_queue_with_trap:
Timeout::Error: execution of assert_in_out_err expired timeout (10 sec)
pid 11608 exit 0
|

    C:/Users/usa/develop/ruby/core/mytree/test/thread/test_queue.rb:553:in `test_queue_with_trap'

[ko1 (Koichi Sasada)]

私も Windows 10 にして再現していました。
私が理解している範囲で、現象をちょっと書いておきます。

(1) GVL に Win32 の Mutex を使っている
(2) Win32 Mutex は、以前はスケジューリングをきちんと（インタプリタ開発者視点）してくれていた。つまり、ある Mutex について、それを待っているスレッド B がある場合、その Mutex を保持していたスレッド A が Mutex を離すと、B の実行が再開されるようになっていた。
(3) Windows 10 にすると（Windows 10 が再現条件か、サンプルが少ないのでなんとも言えないのですが、とりあえず少ない証言から言うと）、スレッド A が Mutex を離しても、スレッド B に処理が素直に渡らなくなった。

というものです。
pthread では、それを回避するために、なんか難しいことをしているのですが、Windows では必要なくて。便利で良かったね、と思っていたんですが、なんか考えないといけないようです。さて、どうしよう。

[usa (Usaku NAKAMURA)]

いちおう、手元(というかなんというか)での再現状況は、

• □ Windows 7
• □ Windows Server 2012 R2 (Windows 8.1相当)
• ☑ Windows 10

という感じです。