[#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:30958] Re: Supporting Fiber

From: SASADA Koichi <ko1@...>
Date: 2007-06-11 19:05:10 UTC
List: ruby-dev #30958
 ささだです。

Yusuke ENDOH さんは書きました:
> 一般的な意味にあわせるのが一番いいと思います。
> 
> 不勉強ながら私は fiber や coroutine 関連の論文や他言語の仕様を
> 読んだことがないので、その答えはわかりません。すみません。



> 私が [ruby-dev:30924] の挙動に違和感を覚えた理由は Fiber の意味を
> callcc の単純なラッパとして理解していて、それと同じ挙動を期待したからです。
> つまり、[ruby-dev:30924] は以下とほぼ等価かと。
> 
> f = proc do |prev|
>  p 1
>  prev.call
>  p 2
> end
> 
> f2 = proc do |prev|
>  callcc {|current| f.call(current) }
> end
> 
> callcc {|current| f2.call(current) }
> 
> # 脳内変換規則
> #  Fiber.new    ==>  proc {|prev| ... }
> #  Fiber#yield  ==>  callcc {|current| self.call(current) }
> 
> 
> しかしこの変換規則だと Fiber を導入する意味がほとんどなさそうなので
> こちらの方が一般的に採用されているとか、便利な例が多そうだということなら、
> 私の違和感は無視してください。

 ほかの言語の例は実は試していないんですが、win32api の Fiber
は SEGV しました。これはあんまりだ。

 確認しているのは lua と modula-2 なんですが、それぞれ Fiber
(Coroutine)の終了時にはどうなるのか教えてくれる人はいないで
すかね。lua なら試せるかな。

 とりあえず、いくつかアプリケーションを作ってみてから考えたほ
うがいいような気がしています。


> あ、あと、呼び出しを Fiber.new { ... }.yield でくくるだけで挙動が変わる
> 関数が定義できてしまうことに抵抗があったというのもあります。
> そういう黒魔術は callcc だけでいい、みたいな。
> 
> def foo
>    Fiber.new do
>        p 1
>        Fiber.prev.yield
>        p 2
>    end.yield
> end
> 
> # Fiber.new do
>    # 何かいろいろやる
>    foo
>    # 何かいろいろやる
>    # Fiber.new でくくっていると忘れた頃に p 2 が実行される
> # end.yield

 表現力の高い coroutine を実現するための仕組みなので、(わか
らないと)不思議なことがあるのはそういうものかなぁ、と思いま
す。また、ほかの例でも同じような現象が起こります。たとえば、
Thread#pass(Thread#critical)では同じようなことが起こります
が、これは黒魔術でしょうか。

 ただし、過剰な自由度は混乱させるだけな気もしています。なの
で、たとえば python のような制限付き coroutine のようにして提
供するのも一案かと思っています。

 ちなみに、python では generator が終了したら例外を返します。
これはこれで納得できる話です。

-- 
// SASADA Koichi at atdot dot net

In This Thread