[#30872] segv when reentering into Fiber with callcc — sheepman <sheepman@...>

こんばんは、sheepman です。

15 messages 2007/06/01
[#30899] Re: segv when reentering into Fiber with callcc — SASADA Koichi <ko1@...> 2007/06/06

 ささだです。

[#30905] Re: segv when reentering into Fiber with callcc — "Yusuke ENDOH" <mame@...> 2007/06/06

遠藤と申します。

[#30906] Re: segv when reentering into Fiber with callcc — SASADA Koichi <ko1@...> 2007/06/06

 ささだです。

[#30929] secrand.rb — "NAKAMURA, Hiroshi" <nakahiro@...>

-----BEGIN PGP SIGNED MESSAGE-----

51 messages 2007/06/08
[#30930] Re: secrand.rb — Tanaka Akira <akr@...> 2007/06/08

In article <4669066C.2080307@sarion.co.jp>,

[#30934] Re: secrand.rb — "NAKAMURA, Hiroshi" <nakahiro@...> 2007/06/08

-----BEGIN PGP SIGNED MESSAGE-----

[#30935] Re: secrand.rb — Tanaka Akira <akr@...> 2007/06/08

In article <46694461.4060706@sarion.co.jp>,

[#30936] Re: secrand.rb — "NAKAMURA, Hiroshi" <nakahiro@...> 2007/06/08

-----BEGIN PGP SIGNED MESSAGE-----

[#30938] Re: secrand.rb — Tanaka Akira <akr@...> 2007/06/08

In article <46697C0B.8060402@sarion.co.jp>,

[#30939] Re: secrand.rb — "NAKAMURA, Hiroshi" <nakahiro@...> 2007/06/08

-----BEGIN PGP SIGNED MESSAGE-----

[#30940] Re: secrand.rb — Tanaka Akira <akr@...> 2007/06/08

In article <4669DAB0.4050705@sarion.co.jp>,

[#30944] Re: secrand.rb — "NAKAMURA, Hiroshi" <nakahiro@...> 2007/06/09

-----BEGIN PGP SIGNED MESSAGE-----

[#30945] Re: secrand.rb — Tanaka Akira <akr@...> 2007/06/09

In article <466AA73C.9030407@sarion.co.jp>,

[#30946] Re: secrand.rb — "NAKAMURA, Hiroshi" <nakahiro@...> 2007/06/09

-----BEGIN PGP SIGNED MESSAGE-----

[#30950] Re: secrand.rb — Nobuyoshi Nakada <nobu@...> 2007/06/11

なかだです。

[#31173] Re: Random — Tanaka Akira <akr@...> 2007/07/10

In article <469253E9.9010203@sarion.co.jp>,

[#31174] Re: Random — "NAKAMURA, Hiroshi" <nakahiro@...> 2007/07/10

-----BEGIN PGP SIGNED MESSAGE-----

[#31178] Re: Random — "NAKAMURA, Hiroshi" <nakahiro@...> 2007/07/11

-----BEGIN PGP SIGNED MESSAGE-----

[#31179] Re: Random — Tanaka Akira <akr@...> 2007/07/11

In article <4694338C.7090303@sarion.co.jp>,

[#31183] Re: Random — "NAKAMURA, Hiroshi" <nakahiro@...> 2007/07/11

-----BEGIN PGP SIGNED MESSAGE-----

[#30971] Linux/ia64で'ucontext_t' undeclared — akira yamada / やまだあきら <akira@...>

最近のRuby 1.9をLinux/ia64上でmakeしようとすると

16 messages 2007/06/13
[#30973] Re: Linux/ia64で'ucontext_t' undeclared — Yukihiro Matsumoto <matz@...> 2007/06/13

まつもと ゆきひろです

[#30974] Re: Linux/ia64で'ucontext_t' undeclared — akira@... 2007/06/13

Yukihiro Matsumoto さんは書きました:

[#30975] Re: Linux/ia64で'ucontext_t' undeclared — Yukihiro Matsumoto <matz@...> 2007/06/13

まつもと ゆきひろです

[ruby-dev:30990] Re: Supporting Fiber

From: "Yusuke ENDOH" <mame@...>
Date: 2007-06-14 18:55:09 UTC
List: ruby-dev #30990
遠藤です。

> 親子関係を利用したプログラミングをしている場合、「親子関係の
> 破壊を起こさなければ」、Fiber#prev が正しく「呼び出し元」を指
> し示すため、SemiCoroutine のような使い方が可能です。

今の Fiber で「親子関係を壊さない範囲」というのはものすごく
狭いと思います。coroutine の中で coroutine を呼び出して
suspend を受けるだけで違反してしまいます。

ささださんの Generator の例も、generator の中で
generator を呼ぶと違反している気がします
(ちゃんと追ってないので勘違いだったらすみません) 。

show Generator.new{|g|
 g.yield 10
 show Generator.new{|g2|
   g2.yield 100
   g2.yield 200
   g2.yield 300
 }
 g.yield 20
 g.yield 30
}


$ ./test.rb
100
200
300
./test.rb:31:in `initialize': unhandled exception
        from ./test.rb:79:in `new'
        from ./test.rb:79:in `<main>'


親を自力で管理して、Fiber.new のブロックの最初で

  @parent = Fiber.prev || Fiber.root

で親を保存して、@fib.suspend の代わりに

  @parent.yield

をすれば動いたような気がしますが、まだ間違ってる気がします。
Fiber.new のブロックの最後でも @parent.yield しないとダメな気も
しますが、今のところ動かない例は見つけられていません。あと、

g = Generator.new{|g|
 g.yield 10
 g.yield 20
 g.yield 30
}

Fiber.new do
  show g
end.yield

が何も出力されないというよくわからない挙動をしますが、
これも Fiber をよくわかってないことが原因の「不思議なこと」でしょうか。


> 余談ですが、現在の Ruby の Continuation は欠陥品で、まともに
> 利用できないシロモノです。具体的には、dynamic-wind 相当の機能
> がありません。なので、「xx の代わりに Continuation を利用」と
> いう選択肢はありえないと考えています。

これは、対等な関係は必要なのかなぁ、といういい加減な気持ちから
適当言いました。すみません。
ちなみに Lua の開発陣?の例の論文によると、semi-coroutine で
coroutine をエンコードできると主張されてました。
# 補助 coroutine を立ち上げて、TRANSFER するときは全てその
# 補助 coroutine を介して呼ぶ感じです。トランポリン?


dynamic-wind についてはお察しの通りよくわかってませんが、例えば
「ブロックを取るメソッドを書くとき、そのメソッドを使う人が
callcc でブロックの中に飛び込むようなことをしたときの対策が
とれない」ってことでしょうか。

callcc は (楽しい楽しい) 黒魔術なので、そういうときは callcc
使用者側の責任だと思っています。あいまいなスタンスですが、外部
ライブラリなしの状態で SEGV しなければ十分かなー、みたいな。

# 私に関しては、普段のプログラミングでは callcc 使いません。
# ぶっちゃけ「おもちゃ取るな!」というレベルの主張です。すみません。


> 個人的には、「主観的な感想」ではたぶん説得力がない気がするの
> で、実際にいくつか現実的な例を出して、プログラミングをしてみて
> から考えるのがいいような気がしています。

ごもっともですが、下手に他の言語で十分練られた設計があるなら
それを盗むのも手かと思わなくもないです。

-- 
Yusuke ENDOH <mame@tsg.ne.jp>

In This Thread