https://redmine.ruby-lang.org/
https://redmine.ruby-lang.org/favicon.ico?1711330511
2010-03-30T07:01:55Z
Ruby Issue Tracking System
Ruby master - Bug #3050: Fiber transfer limitation
https://redmine.ruby-lang.org/issues/3050?journal_id=9522
2010-03-30T07:01:55Z
matz (Yukihiro Matsumoto)
matz@ruby.or.jp
<ul></ul><p>=begin<br>
まつもと ゆきひろです</p>
<p>In message "Re: <a href="/issues/3050">[ruby-dev:40833]</a> [Bug: trunk] Fiber transfer limitation"<br>
on Tue, 30 Mar 2010 04:19:56 +0900, SASADA Koichi <a href="mailto:ko1@atdot.net" class="email">ko1@atdot.net</a> writes:</p>
<p>| 1.9.2 に入れて欲しい Fiber に関する仕様変更について,一つ忘れていました.<br>
|<br>
| 現在,Fiber#transfer と Fiber.yield/Fiber#resume は一緒に使うな,使っ<br>
|て変なことが起きても知らないよ,という立場を取っています.というのも,一<br>
|緒に使うと簡単に SEGV させることが出来るからです.</p>
<p>| そこで,Fiber#resume をした,つまり Fiber.yield する先がある Fiber に<br>
|関しては transfer を禁止しようと思います.また,一度でも Fiber#transfer<br>
|された先の Fiber を resume 出来ないようにしようと思います.</p>
<p>暗黙の禁止はドキュメントに書いても誰も読まないので(いいす<br>
ぎ?)、明示的に禁止するのは良いことではないかと思います。</p>
<p>=end</p>
Ruby master - Bug #3050: Fiber transfer limitation
https://redmine.ruby-lang.org/issues/3050?journal_id=10745
2010-05-03T22:57:23Z
mame (Yusuke Endoh)
mame@ruby-lang.org
<ul><li><strong>Category</strong> set to <i>core</i></li><li><strong>Assignee</strong> set to <i>ko1 (Koichi Sasada)</i></li><li><strong>Target version</strong> set to <i>1.9.2</i></li><li><strong>ruby -v</strong> set to <i>-</i></li></ul><p>=begin<br>
遠藤です。</p>
<blockquote>
<p> 現在,Fiber#transfer と Fiber.yield/Fiber#resume は一緒に使うな,使っ<br>
て変なことが起きても知らないよ,という立場を取っています.というのも,一<br>
緒に使うと簡単に SEGV させることが出来るからです.</p>
</blockquote>
<p>混ぜると理解困難な挙動になるのは確かなんですが、SEGV するとは<br>
知りませんでした。<br>
この例に関しては、最後のパッチで SEGV はしなくなると思います。</p>
<blockquote>
<p> 例えば前者が出来るクラスを Coroutine,後者が出来るクラスを<br>
SemiCoroutine として提供して混ぜないようにするという手段もあるのですが,<br>
大クラス主義の Ruby とはなじみません.</p>
</blockquote>
<p>大クラス主義は「概念的に似ているものに複数のクラスを作らない」<br>
だと思います。<br>
Coroutine と SemiCoroutine は実装はほとんど共通しているものの、<br>
概念的にはかなり異なっていると感じます。goto と function call<br>
くらいには違いますよね。<br>
なので、別の名前にしてもよかったんじゃないかなあ。今更ですが。</p>
<p><a href="https://blade.ruby-lang.org/ruby-dev/31596">[ruby-dev:31596]</a> 以来、transfer は用途がわからないわりに混乱を<br>
招くと言う「百害あって一利なし」だと思うので、なければよかった<br>
のにと思っています。</p>
<p>diff --git a/cont.c b/cont.c<br>
index 185d812..b4b486d 100644<br>
--- a/cont.c<br>
+++ b/cont.c<br>
@@ -945,9 +945,15 @@ fiber_switch(VALUE fibval, int argc, VALUE *argv, int is_resume)<br>
}<br>
else if (fib->status == TERMINATED) {<br>
value = rb_exc_new2(rb_eFiberError, "dead fiber called");</p>
<ul>
<li>if (th->fiber != fibval) rb_exc_raise(value);</li>
<li>fibval = fib->prev;</li>
<li>if (NIL_P(fibval)) fibval = th->root_fiber;</li>
</ul>
<ul>
<li>if (th->fiber != fibval) {</li>
<li>
<pre><code> GetFiberPtr(th->fiber, fib);
</code></pre>
</li>
<li>
<pre><code> if (fib->status != TERMINATED) rb_exc_raise(value);
</code></pre>
</li>
<li>
<pre><code> fibval = th->root_fiber;
</code></pre>
</li>
<li>}</li>
<li>else {</li>
<li>
<pre><code> fibval = fib->prev;
</code></pre>
</li>
<li>
<pre><code> if (NIL_P(fibval)) fibval = th->root_fiber;
</code></pre>
</li>
<li>}<br>
GetFiberPtr(fibval, fib);<br>
cont = &fib->cont;<br>
cont->argc = -1;</li>
</ul>
<p>--<br>
Yusuke Endoh <a href="mailto:mame@tsg.ne.jp" class="email">mame@tsg.ne.jp</a><br>
=end</p>
Ruby master - Bug #3050: Fiber transfer limitation
https://redmine.ruby-lang.org/issues/3050?journal_id=10767
2010-05-04T12:04:11Z
ko1 (Koichi Sasada)
<ul></ul><p>=begin<br>
ささだです.</p>
<p>(2010/05/03 22:57), Yusuke Endoh wrote::</p>
<blockquote>
<blockquote>
<p> 現在,Fiber#transfer と Fiber.yield/Fiber#resume は一緒に使うな,使っ<br>
て変なことが起きても知らないよ,という立場を取っています.というのも,一<br>
緒に使うと簡単に SEGV させることが出来るからです.</p>
</blockquote>
<p>混ぜると理解困難な挙動になるのは確かなんですが、SEGV するとは<br>
知りませんでした。<br>
この例に関しては、最後のパッチで SEGV はしなくなると思います。</p>
</blockquote>
<p> 新しい仕様を考えるのはしんどそうだし,SEGV しなくなればとりあえず良い<br>
と思いますので,遠藤さんを信じます.<br>
</p>
<blockquote>
<blockquote>
<p> 例えば前者が出来るクラスを Coroutine,後者が出来るクラスを<br>
SemiCoroutine として提供して混ぜないようにするという手段もあるのですが,<br>
大クラス主義の Ruby とはなじみません.</p>
</blockquote>
<p>大クラス主義は「概念的に似ているものに複数のクラスを作らない」<br>
だと思います。<br>
Coroutine と SemiCoroutine は実装はほとんど共通しているものの、<br>
概念的にはかなり異なっていると感じます。goto と function call<br>
くらいには違いますよね。<br>
なので、別の名前にしてもよかったんじゃないかなあ。今更ですが。</p>
<p><a href="https://blade.ruby-lang.org/ruby-dev/31596">[ruby-dev:31596]</a> 以来、transfer は用途がわからないわりに混乱を<br>
招くと言う「百害あって一利なし」だと思うので、なければよかった<br>
のにと思っています。</p>
</blockquote>
<p> continuation と合わせて,gem とかに追い出しちゃえばよかったかなぁ.</p>
<p> ちなみに,Control flow を制御する,という意味で,私の中ではやっぱり同<br>
じものってカテゴリーに.</p>
<p>--<br>
// SASADA Koichi at atdot dot net<br>
=end</p>
Ruby master - Bug #3050: Fiber transfer limitation
https://redmine.ruby-lang.org/issues/3050?journal_id=10768
2010-05-04T12:04:32Z
ko1 (Koichi Sasada)
<ul></ul><p>=begin<br>
ささだです.</p>
<p>(2010/05/03 22:57), Yusuke Endoh wrote::</p>
<blockquote>
<blockquote>
<p> 現在,Fiber#transfer と Fiber.yield/Fiber#resume は一緒に使うな,使っ<br>
て変なことが起きても知らないよ,という立場を取っています.というのも,一<br>
緒に使うと簡単に SEGV させることが出来るからです.</p>
</blockquote>
<p>混ぜると理解困難な挙動になるのは確かなんですが、SEGV するとは<br>
知りませんでした。<br>
この例に関しては、最後のパッチで SEGV はしなくなると思います。</p>
</blockquote>
<p> 新しい仕様を考えるのはしんどそうだし,SEGV しなくなればとりあえず良い<br>
と思いますので,遠藤さんを信じます.<br>
</p>
<blockquote>
<blockquote>
<p> 例えば前者が出来るクラスを Coroutine,後者が出来るクラスを<br>
SemiCoroutine として提供して混ぜないようにするという手段もあるのですが,<br>
大クラス主義の Ruby とはなじみません.</p>
</blockquote>
<p>大クラス主義は「概念的に似ているものに複数のクラスを作らない」<br>
だと思います。<br>
Coroutine と SemiCoroutine は実装はほとんど共通しているものの、<br>
概念的にはかなり異なっていると感じます。goto と function call<br>
くらいには違いますよね。<br>
なので、別の名前にしてもよかったんじゃないかなあ。今更ですが。</p>
<p><a href="https://blade.ruby-lang.org/ruby-dev/31596">[ruby-dev:31596]</a> 以来、transfer は用途がわからないわりに混乱を<br>
招くと言う「百害あって一利なし」だと思うので、なければよかった<br>
のにと思っています。</p>
</blockquote>
<p> continuation と合わせて,gem とかに追い出しちゃえばよかったかなぁ.</p>
<p> ちなみに,Control flow を制御する,という意味で,私の中ではやっぱり同<br>
じものってカテゴリーに.</p>
<p>--<br>
// SASADA Koichi at atdot dot net</p>
<p>=end</p>
Ruby master - Bug #3050: Fiber transfer limitation
https://redmine.ruby-lang.org/issues/3050?journal_id=10897
2010-05-10T02:37:06Z
mame (Yusuke Endoh)
mame@ruby-lang.org
<ul><li><strong>Status</strong> changed from <i>Open</i> to <i>Closed</i></li><li><strong>% Done</strong> changed from <i>0</i> to <i>100</i></li></ul><p>=begin<br>
This issue was solved with changeset r27713.<br>
Koichi, thank you for reporting this issue.<br>
Your contribution to Ruby is greatly appreciated.<br>
May Ruby be with you.</p>
<p>=end</p>