Project

General

Profile

Bug #14727

TestQueue#test_queue_with_trap always timeout on Windows10

Added by usa (Usaku NAKAMURA) about 1 year ago. Updated about 1 year ago.

Status:
Assigned
Priority:
Normal
Target version:
-
ruby -v:
ruby -v: ruby 2.6.0dev (2018-05-01 trunk 63310) [x64-mswin64_140]
[ruby-dev:50528]

Description

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

[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'

History

Updated by ko1 (Koichi Sasada) about 1 year ago

私も 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 では必要なくて。便利で良かったね、と思っていたんですが、なんか考えないといけないようです。さて、どうしよう。

Updated by usa (Usaku NAKAMURA) about 1 year ago

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

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

という感じです。

Also available in: Atom PDF