回答編集履歴

2

その後の動きについて追記した。

2016/07/02 22:10

投稿

eripong
eripong

スコア1546

test CHANGED
@@ -13,3 +13,35 @@
13
13
 
14
14
 
15
15
  この辺りを見ると、諦めているようにも見えます。。。
16
+
17
+
18
+
19
+ ---
20
+
21
+ 今ひとつ流れを掴めてないですが、
22
+
23
+ [WIP: V8 upgrade by stormbreakerbg · Pull Request #334 · cowboyd/therubyracer](https://github.com/cowboyd/therubyracer/pull/334)
24
+
25
+ に、
26
+
27
+ > This is fantastic! I would love to see this make it across the goal line, and will help you in whatever way I can!
28
+
29
+ If you are going to take on this effort, there are a couple of things to consider. First, I think we should remove all locking of V8 from Ruby entirely.
30
+
31
+
32
+
33
+ とあり、
34
+
35
+
36
+
37
+ [Upgrade to v8 4.5, move towards 1.0 release by cowboyd · Pull Request #348 · cowboyd/therubyracer](https://github.com/cowboyd/therubyracer/pull/348)
38
+
39
+
40
+
41
+ に続いているようなので、therubytracerが1.0になれば解決するかも知れません。
42
+
43
+
44
+
45
+ 細かく内容を追ってないので間違っていたらすみません。
46
+
47
+

1

引用を追記した。

2016/07/02 22:10

投稿

eripong
eripong

スコア1546

test CHANGED
@@ -5,3 +5,11 @@
5
5
  でしょうか。
6
6
 
7
7
  未解決みたいです。
8
+
9
+
10
+
11
+ > Like Ruby, V8 also has a global interpreter lock, and so only one thread can be executing code inside the V8 VM at a time. The answer is, I think, to release the GIL where possible when entering the V8 VM, and then reacquire it if and when V8 calls back into Ruby. This may be incompatible with the current strategy of acquiring the V8 lock from within Ruby code.
12
+
13
+
14
+
15
+ この辺りを見ると、諦めているようにも見えます。。。