トップ «前の日記(2009-03-23) 最新 次の日記(2009-03-26)» 編集

Route 477



2009-03-24

[scheme][memo] R6RS処理系

インストール状況:

(petite) chez scheme
Ypsilon Scheme System
Ikarus Scheme
Mosh
PLT Scheme
まだ http://download.plt-scheme.org/
Larceny
途中
IronScheme
まだ。mono使えばMacでも動かせるようだ。

[link] 認証と認可

twitterのパスワードを要求するマッシュアップはいっぱいありますが、OAuthに対応してくれればパスワードを個々のサービスに渡さなくても済むようになりますね

[秋元@男子産前休暇ブログ » twitterのOAuthが一般利用可能により引用]

OAuthってなんだろう。

OpenIDになんとなく似てるけど、OpenIDがログイン情報を扱うのに対し、OAuthはアクセス制御を行うらしい。

OAuthを解説したページに、こんな文章が。

分かりやすく「認証」と「アクセス制御」って書いたけど、一般的には「認証 (Authentication)」と「認可 (Authorization)」と呼ぶみたい。

[WebAPI のアクセス制御に使える OAuth という仕様 - まちゅダイアリー(2007-09-25)より引用]

ほうほう。

認証(Authentication)

そのユーザーが自分の物であると主張するIDに対して、そのIDが確かにそのユーザーの物であるということを保証すること

認可(Authorize)

認証されたIDを受け入れ、サービスに対して適切な権限を与えること

[仕様から学ぶOpenIDのキホン − @ITより引用]

[prog] 並行・並列・分散

ついでに、並行・並列・分散の違いも思い出す。

分散処理(distributed processing)
複数のマシンで実行。
並列処理(parallel processing)
マシンは一台だが、複数のCPUコアで実行。
並行処理(concurrent processing)
複数のタスクを並行して実行。マシンの台数やCPUコアの数は関係ない。

ということは迷ったら「並行処理」って言っとけばいいわけだね(おい)。

(3/28追記:字が間違ってた(´・ω・`) 平行→並行)

[ruby][prog] Fiber(とコルーチンとcall/cc)についていろいろ考えた

Kansai.pmのはこべさんの発表とか、その後の話からいろいろ考えた。

FiberとWebアプリ

  • Fiberを使って、ステートフルなWebフレームワークが作れるはず。
    • リクエストが来るたびに、少しずつFiber内の処理を進めていく。いわゆる「継続ベース」のWebフレームワークのように。
    • ただし同じポイントから再度繰り返すことはできない(call/ccベースではないので)。まぁ繰り返したいことってそんなにないと思う…アンドゥの実装には便利かもしれない?
  • Fiberの利用例だとNeverBlockが有名だけど
    • NeverBlockって何だっけ?
    • MySQLのクエリをブロックしないようにするらしい
    • findとか読んだときに結果が返るまでじっと待つんじゃなくて、Fiber.yieldで中断して、待ち時間に別のことをする
    • 別のことって…?
    • うーん、もうちょっと調査が必要そうだ(^^; → steps to phantasien(2008-09-20)
  • 1つのページをレンダリングするときも、並列できる箇所はあるよね
    • たとえばはてブトップなら、ヘッダ部分と「人気エントリー」と広告の部分で必要なデータは独立だが、上から順にレンダリングするとSQLの呼び出しごとにブロックしてしまう
    • これFiberでなんとかならない?
    • 各ブロックを独立したFiberにする。フレームワーク側がそれらを管理していて、SQLの呼び出しが発生するとFiberを中断させ、SQLの結果が取得できるまで別のFiberの計算を実行しておく。
    • 理想をいえば、Fiberに切り分ける部分も自動でやってほしい(テラ未来www)
      • 変数の使用範囲とかを解析したらいけるんじゃないかなぁ
      • evalってこういうのとすげー相性悪いよね
      • というか動的さはコードの解析を難しくする
      • ということはいずれコードが解析しやすい言語が有利になる?コードを解析することで、性能を上げる。メタプログラミング。
      • と言ってみたものの変数の生存解析とかはぜんぜん詳しくないのでよく分からん

Fiberの使い道

  • ゲームしかないのか?
    • そもそも複数の処理を平行して走らせたい場面って限定されるよねぇ…。
  • C#のジェネレータはプログレスバーとか出すのに便利らしい。
    • ということは、「ディレクトリを再帰的に辿りながら総サイズを計算するような関数」をFiberで中断してプログレスバーを更新するようなデモを書くと格好いいと思われ。
  • Coro自体は単なるコルーチンよりも(強力|用途が広い)ようだ。
    • コルーチンを実装しようとしたらえらい低レベルからいじらないといけなくて、その結果いろんなことができるようになった、っていう感じなのかなぁ。
    • Coro::stateのclone関数を呼ぶことで(多少の制限はあるけど)call/cc相当のことができるらしい
    • セマフォとか、並行処理全般を扱うライブラリ群らしい。(一覧)
    • いくつかはRubyのFiberにも応用できるんじゃないかなぁ。

ジェネレータとかcall/ccとか

先にまとめておくと、

  • Fiber相当(コルーチン):
    • Ruby 1.9のFiber
    • C#/Python/JS1.7のジェネレータ(あのyield使うやつ。Rubyのyieldとは意味が異なる)
    • Luaのcoroutine
    • はこべさんのCoro::Fiber
  • call/cc相当(再入ができる):
    • Schemeのcall/cc
    • Rubyのcallcc (1.9からはrequire 'continuation'が必要)
    • RhinoのContinuationクラス
    • PerlのCoro::State(のclone関数)
    • Cyanのreturn
  • Fiberとcall/ccの違いは、停止したFiberは「一度しか」再開しかできないのに対し、call/ccはある地点から「二度以上」実行されることがある点。
    • だからcall/ccはある時点の処理系の状態を「コピー」しなければならない(2回目に実行されるときのために)。なので普通はコルーチンよりも重い。
  • というか「call/cc」という表現は適当じゃないかも。
    • call/ccは、(A) 継続をオブジェクトとして取り出せる機能 と (B) 継続オブジェクトを指定した関数に渡す機能 に分解できる。重要なのは(A)の方であって、(B)の方は単にAPIのインターフェイスの問題に過ぎない。
    • RhinoのContinuationクラスはSchemeのcall/ccとインターフェイス((B)の部分)が異なるけれど、(A)の部分の機能は同じ。だからやれることは変わらない(はず)。