議論/ストリーム


Top / 議論 / ストリーム

ストリーム

以前から標準入出力については取り沙汰されていましたが、 議論/実用化に必要な事でもまたその話題が出ました。

ここでは標準入出力をストリームの応用として位置付ける前提で、 ストリームについて考えます。

Tinoの提案

ストリーム原案

使うときのイメージを疑似コードで表現します。

作成

  1. Stream* s = new Stream();
    • キューはデフォルトのサイズ。64KBくらいが妥当?
  2. Stream* s = new Stream(1024 * 1024);
    • キューのサイズを指定。この例では1MB。
  3. Stream* s = Stream::FromHandle(handle);
    • ストリームはプロセス間通信のためのものなので、他プロセスからハンドルが渡されるという使い方も、当然考慮しないといけない。この辺の考え方はmonapi_cmemoryinfo(共有メモリ)と同じ。
    • C言語との整合性を考えて意図的にmonapi_cmemoryinfoはクラスにしなかったのと同様、Streamもクラスにしない方が良いかもしれません。
      • D言語方面を強化するなら尚更その方が都合が良いかもしれません。

書き込み

int len = s->write(buf, 256);

s->waitForWrite();

読み込み

int len = s->read(buf, 256);

s->waitForRead();

その他

以下はstd::vectorに準拠した関数名です。

int size = s->size();

int len = s->capacity();

実装 by ひげぽん

行きの機内でStreamをでっちあげました。カーネルには手を入れていません。まだ不具合があってたまに落ちます。

コメント

最新の1000件を表示しています。 コメントページを参照

お名前:
  • Monaプロジェクトの問題点等は別の場所で議論します。実装にフォーカスしてストリームを先にすすめていただきます。 -- ひげぽん 2006-10-06 (金) 23:27:01
  • ひげぽんの「しつこくてごめんなさい。すっきりしたいだけなので(略)」から話の流れがおかしな方に向いてるように思います。現在の話の流れは、このページで話したい事が何か明瞭でなくなっている様に見えました。このページで話したい事は何でしょうか?(ひげぽんとTinoさんのやり取りが揉めている様にみえました) -- Gaku 2006-10-04 (水) 00:17:55
    • お騒がせして申し訳ありません。以前にも直接個人間のやり取りで揉めることがあったということをお話ししましたが、まさにこのような展開を何度も繰り返したのでした。最初は激高して「もう二度とMonaには関わらない」と思ったりしましたが、今はもう慣れてしまって、怒りの感情は特になく、こうなった場合どのように出口を探ればよいのだろうと考えて、敢えて続けていました。結局、話がそれても突っ込まずに折れるのが無難かな、というのが現時点での印象です。 -- Tino 2006-10-04 (水) 00:28:23
    • このページでの話の流れをみて思うに、話題が分散しています。(「話題=何を話したいのか?」が一度に多岐に渡っているように見えます)構図としてはこんな感じ(→)かなぁと思いました。「ひげぽんとTinoさんでキーワードに対してすれ違った解釈をする。→ひげぽんが疑問とか外したコメントをする。→Tinoさんが全部に速攻で回答する。→話題が分散したまま話が進んで、すれ違いが深刻化する。」自分の意見はページにまとめて書くとして、議論は、言いたい事が通じたか確認しながら出来ると良いのですけど。なかなか難しいですね。(ページに自分の考えをまとめて、どう思う?と聞いたら相手は別のページにおれはこう思うんだけど。とまとめて書く位のほうが大量に意見をやり取りする際は良かったりします?1コメントづつやり取りして、どんどん話が逸れるよりは良い?) -- Gaku 2006-10-04 (水) 02:14:48
    • ご忠告ありがとうございます。正直言いまして、私自身、何が目的の話なのかよく分からなくなっているので、コメントを全部拾って話題別に整理してみたいと思います。私の自己矛盾等が表面化すればそれも反省材料にして今後に生かすのが目的です。 -- Tino 2006-10-04 (水) 09:00:36
    • ./反省材料で分析をしてみました。意図的に距離を置くようにして、何かコメントするときも散発的を心掛けるようにするという結論になりました。お目汚し誠に申し訳ありませんでした。 -- Tino 2006-10-04 (水) 19:37:07
  • すみません。何回も読み直したのですが良く分かりませんでした。そうのように、そういう結論、そのように考えてものあたりが分からないです。 -- ひげぽん 2006-10-03 (火) 21:48:54
    • (ageました)「逆・裏・対偶」 -- Tino 2006-10-03 (火) 23:24:20
  • 知っています。参照ドキュメントは「最終更新: 1999/02/17 23:58:45」ですね。僕の感覚では「レス」も十分浸透してきたという印象です。これを見て怒る人を否定する訳ではありませんけど。 -- ひげぽん 2006-10-03 (火) 21:50:44
    • (ageました)僕の感覚では「レス」も十分浸透してきたという印象です。⇒こういうのを一般的に「一言多い」と言います。もしレスという表現を不愉快に思う人がこのやり取りを見ていたらどういう気持ちになるでしょうか? -- Tino 2006-10-03 (火) 22:42:28
  • 私が考えているストリームの本質はキューです。プロセス間同期等はオプショナルなものに過ぎません。従って単なるコレクションクラスの一種だと考えているため、最初の取っ掛かりはOSに依存する部分などまるでなく、セマフォすら出て来ません。そのため「標準出力まで実装しました。でも落ちます。ここまで来るとエミュレーションは手間がかかるだけです。」と言われたことに対して「先走り」だと感じました。 -- Tino 2006-10-03 (火) 23:05:58
    • 「ストリームの本質はキュー」という考え方から、「Messenger.hのclass Messenger { int size_, allocated_; MessageInfo* info_; };の部分のことを指して、ストリームそのものではないか」という考え方が出てきます。 -- Tino 2006-10-03 (火) 23:38:26
  • で、本質的な議論に戻ると、Tinoさんはセマフォを使ってLinux上で実装するべきだと言っていて、ひげぽんはLinux上で実装するのはありかもしれない、メッセージで到着を知らせるのは全然ありなんじゃないかな、もうすこしMona上でデバッグがんばってみようかなと思っています。という状況です。 -- ひげぽん 2006-10-03 (火) 22:44:06
    • 本質的な議論とまで言い切るのであれば、セマフォよりメッセージが優れている点を説明してみていただけないでしょうか。納得できる理由であれば、無下に突っかかることはしませんので。 -- Tino 2006-10-03 (火) 23:01:22
    • Monaのカーネルに手を入れずにユーザー側だけで気軽にStreamを実装できることでしょうか。 -- ひげぽん 2006-10-03 (火) 23:03:15
    • 何のためにMonaのカーネルに手を入れるのですか? -- Tino 2006-10-03 (火) 23:06:41
    • waitForRead/waitForWriteのwait/wakeupをビジーループ以外で行いたいからです。 -- ひげぽん 2006-10-03 (火) 23:08:08
    • なぜビジーループになるのですか? -- Tino 2006-10-03 (火) 23:10:00
    • 共有メモリに対する、他のプロセスの書き込みがあるかどうかを知るためにポーリングの必要があるからです。 -- ひげぽん 2006-10-03 (火) 23:11:38
    • もどかしい(w。何を意図した誘導尋問か分かりますか? -- Tino 2006-10-03 (火) 23:15:09
    • 分かりません。 -- ひげぽん 2006-10-03 (火) 23:17:57
    • (間違っていたら指摘してください。)Monaのユーザー側にセマフォはない。カーネルにはあるがwhile (Semaphore::down(&g_semaphore_shared));のようにビジーループ。「Mutex=Binary Semaphore」とあることから、Mutexはセマフォの限定版と考えられるが、Monaはそのような実装になっていない。Mutexはちゃんとポーリングする。 -- Tino 2006-10-03 (火) 23:35:33
      • Monaのユーザー側にセマフォはない→OK。のようにビジーループ→OK。Mutexはちゃんとポーリングする→分からないです。やはりMutex/Semaphoreの定義が僕と違うように思えます。そこが心配です。 -- ひげぽん 2006-10-03 (火) 23:42:31
      • 質問の意味が分かりました。回答はMutexはブロックされるのでビジーループではありません。 -- ひげぽん 2006-10-03 (火) 23:47:10
      • すみません。表現が悪かったです。Mutexによりアイドリングすると言えば良かったでしょうか。つまり言いたいことはビジーループの反対です。 -- Tino 2006-10-03 (火) 23:54:49
      • 補足しておくと、ひげぽんさんご自身の口から「Mutex=Binary Semaphore」と出ていますが、Monaの実装はそのように(セマフォの限定版としてMutexを実装)なっていないことを突っ込んでもいます。誤解があるといけないので別の言い方をすると、Binary Semaphoreという表現から、セマフォが先にあって、それを特殊化したものとしてMutexを実装していれば、Mutexだけアイドリングするということにはならないはずだ、ということです。 -- Tino 2006-10-04 (水) 00:01:05
      • そのように実装するべきだと言っているわけではありません。説明と実装が食い違うので「あれ?」と感じたというだけのことです。 -- Tino 2006-10-04 (水) 00:02:06
    • つまりセマフォのことを言わせようとしたのに、セマフォが出てこないから、もどかしいわけです。 -- Tino 2006-10-03 (火) 23:36:24
    • もう面倒なので結論を言いますが、アイドリングしてくれるセマフォがないからメッセージを使うしかないということを説明していただければ、納得できたわけです。長々と引っ張るような内容ではないですよね。セマフォのことを聞いているのにセマフォに言及されていないからネチネチと誘導尋問を続けていたわけです。 -- Tino 2006-10-03 (火) 23:56:52
  • 【回答の都合上インデントを下げてageました】以下ひげぽんコメントです。 -- ひげぽん 2006-10-03 (火) 21:56:10
    • 「実装に対して何か書かないといけない」→何らかの感想コメントを期待していたのでひげぽんの想定通り。本音をいえばとりあえずコードを書き起こしたことを褒めて欲しかったのかもしれません。
    • 「手法として標準化されたはずの「まず汎用OS上で実装する」という手順から外れている」→必ず守らないといけないものではないと認識してほしいという点が1点。Linuxでテストすると楽かもしれないという点には同意。
      • 私は「まず最初にLinuxで実装を試みられるかと想定していたので、必然的にセマフォが出てくるかと思ったからです。」と書いたように、そういう方向に話を進めようとしていました。Monaの実装を既成事実として出して「必ず守らないといけないものではないと認識してほしい」と言われても、「もうやっちゃったんだから仕方ない」ということであると感じます。 -- Tino 2006-10-03 (火) 22:53:31
    • 「「同じ構造のものを他のOSで実装」と指摘しました」→「同じ構造のものを他のOSで実装して、それが落ちたりしなければ、問題はStreamではないとしか答えようがないです」の事ですね。言いたかった内容は理解できますが、なぜ僕が質問している訳ではないのに「答えようがない」と言われているのかが分かりません。
      • コメントを書くことを「答える」と表現しました。「〜を見て欲しい」とコメントを求められることと「質問」とは、それを受ける側としてはどちらも「回答」だという認識です。いつも小手先の表現で揉めて本題に入る前に話がおかしな方向に行きます。 -- Tino 2006-10-03 (火) 22:18:02
    • 「ちょっと話が飛びすぎです。いきなり標準入出力とは」→これはどういう意図のかき込みでしょうか。
      • ストリームに対する認識が紛糾している状態で、先に進んでどう話し合うつもりなのでしょうか。ということです。 -- Tino 2006-10-03 (火) 22:24:46
      • 私に見せるつもりでなく、自分が実装が進めばそれで構わないということであれば、別に合意を得る必要もありません。ただしその場合、私にコメントを求めるのは支離滅裂です。 -- Tino 2006-10-03 (火) 22:26:31
      • いきなり「標準入出力とは」は僕のどの書き込みに対するものでしょうか。それが分からないです。「私に見せるつもりでなく、自分が実装が進めばそれで構わないということであれば、別に合意を得る必要もありません。ただしその場合、私にコメントを求めるのは支離滅裂です」→支離滅裂ではないと思います。Tinoさんが仕様を提案したStreamをまだ途中ですが実装しましたと、報告することには一定の意味があると思います。議論が紛糾しているのであれば第3者に突っ込んでもらうのが良いんですね。 -- ひげぽん 2006-10-03 (火) 22:32:49
      • いきなり「標準入出力とは」は僕のどの書き込みに対するものでしょうか。⇒ stdoutclienttest & stdoutservertest -- Tino 2006-10-03 (火) 22:36:16
      • あぁ。申し訳ないです。それは僕が悪い。標準出力をイメージしてテストしていたもので。 -- ひげぽん 2006-10-03 (火) 22:37:59
      • もし可能ならば、混乱しそうな場合は、コメントを書いていただくときに引用元を明記してもらえると助かります。(混乱をなくすため) -- ひげぽん 2006-10-03 (火) 22:38:53
      • 報告することには一定の意味があると思います。⇒火に油を注ぐ意味でしょうか。煽っているわけでなくても、こんなことを言われたらそう感じるのが普通だと思いますが。 -- Tino 2006-10-03 (火) 22:39:32
      • 議論が紛糾しているのであれば第3者に突っ込んでもらうのが良いんですね。⇒私のことは構わずにご自分の道を進むのが良いと思いますが。 -- Tino 2006-10-03 (火) 22:41:05
      • それは悪くとりすぎです。このあたりは感情論になりがち(感情的ととられがち)なので第3者のコメントがあるまでは深入りしない方が良さそうです。 -- ひげぽん 2006-10-03 (火) 22:41:42
      • 冷静に考えてみてください。第三者がどうとかの前に、話が紛糾している段階で一方的に報告されたら、この人は話し合う気があるのだろうかと思うのが普通だと思います。内容が正しいとか間違っているとか以前にマナーの問題です。 -- Tino 2006-10-03 (火) 22:46:07
    • 「何はともあれデバッグは汎用OS上でやりましょうと」→デバッグ効率とエミュレーションのバランスで実装開始時は、Mona上で開発するのがベストだと判断しています。
      • エミュレーションという表現に違和感を感じました。理由は上に書いた通り、セマフォを使うだけで、エミュレーションも何もないからです。 -- Tino 2006-10-03 (火) 22:31:09
  • あとこれは余談なのですが、UNIX古参の人は「レス」という単語に過剰反応する人がいるということはご存知でしょうか?(この辺を参照)。実際に、初心者が何の気なしにMLで「レス」と書いたら、いきなり絡まれてフレームになったのを何度か見たことがあります。 -- Tino 2006-10-02 (月) 23:41:59
  • 自分も火をつけといてあれですが、どちらがプリミティブとかセマフォだのメッセージがどうこうという話よりも、叩き台のコードを元に標準入出力の実装まで妄想する方が楽しいんじゃないかと思いました。不具合はありつつも既に動くコードが出来たということに焦点があたっても良いかなあと。 -- ひげぽん 2006-10-02 (月) 22:55:57
    • 下に書いたように、私は一般論ではなく、具体的な実装を念頭に発言していたつもりなのですが、それが噛み合わないので、こういう展開になっているのだと思います。その辺の誤解をちゃんと解消しないと、すぐまたこういう展開になりますよ。 -- Tino 2006-10-02 (月) 23:06:04
      • 誤解があったようですみません。このかみ合わない議論が進んだ原因を分析するのが良さそうですね。 -- ひげぽん 2006-10-03 (火) 21:52:40
    • 「不具合はありつつも既に動くコードが出来たということに焦点があたっても良いかなあと。」⇒下の方の「どの書き込みに対するレスですか」と一緒に回答します。まず私は連絡帳で「Streamの叩き台を実装しました議論/ストリーム>Tinoさん」と書いてあるのを見て、実装に対して何か書かないといけないと思ったのですが、「まだ不具合があってたまに落ちます」とあるように、何か突っ込んでも「まだ作りかけです。これからデバッグします」というやり取りになるのがオチだと思って、それならと、手法として標準化されたはずの「まず汎用OS上で実装する」という手順から外れているということを「同じ構造のものを他のOSで実装」と指摘しました。そうしたら「その件に関してTinoさんに何かを期待したり依頼をしてはいない」という当初の予想(まだ作りかけです。これからデバッグします=そこは突っ込みどころではない)通りの回答が返って来ました。ですが前述のようにそこに突っ込む気はなくて、何はともあれデバッグは汎用OS上でやりましょうということを書いたのです。 -- Tino 2006-10-02 (月) 23:34:00
  • 違います<標準入出力。「メッセージとストリームのどちらがプリミティブか」という議論は両方をプリミティブに実装してみて、実際に両方を違う場面で使ってみればどちらがプリミティブか個人的な判断の材料になるであろうという話です。 -- ひげぽん 2006-10-02 (月) 21:34:00
    • (ageました)これまた話が噛み合っていませんが、私は一般論ではなく特定の実装を念頭に置いて発言しています。具体的にはMessenger.hのclass Messenger { int size_, allocated_; MessageInfo* info_; };の部分のことを指して、ストリームそのものではないかということを書いたのです。ここで私が想定しているストリームと言うのは上のStream.cppのようにプロセス間通信のことまで想定したものではなく、単なるキューのことを言っています。「そのように考えればそういう結論になる」ということを言っているので、「そのように考えなければそのような結論にならない」というのは反論ではなく別のことを言っているだけです。反論であれば「そのように考えてもそのような結論にならない」という内容になるはずだからです。ここまでよろしいでしょうか?>ひげぽんさん -- Tino 2006-10-02 (月) 22:49:05
  • Stream.cppを見てみましたが、セマフォではなくメッセージで通知が来ていますね。Mutexとメッセージの組み合わせというのはMonaServerと同じです。私がセマフォセマフォとしつこく言っていたのは、メッセージを使わないで実装することを念頭に置いていました。なぜかというと、まず最初にLinuxで実装を試みられるかと想定していたので、必然的にセマフォが出てくるかと思ったからです。 -- Tino 2006-10-02 (月) 22:37:20
  • メッセージとストリームを標準入出力の実装として比較するのであれば、どれくらいの速度が出せるかという定量的な面に着目すると良いでしょう。標準入出力に限らず、ドライバなどで大量のデータを転送するなどの面でも必要なので、最低でも1MB/sくらいは出す必要があります。 -- Tino 2006-10-02 (月) 19:13:35
    • 訂正です。一度に1MBのデータを書き込めば余裕で1MB/sは出るので、最高速度議論は無意味でした。同じ処理(細切れに大量のデータを送る等)をやって、速度を計測するようなテストでないと意味がなかったです。 -- Tino 2006-10-02 (月) 19:36:58
  • ちょっと話が飛びすぎです。いきなり標準入出力とは。それはともかく、同じ構造のものを他のOSで実装して、それが落ちたりしなければ、問題はStreamではないとしか答えようがないです。 -- Tino 2006-10-02 (月) 18:55:30
    • ん?どの書き込みに対するレスですか。 -- ひげぽん 2006-10-02 (月) 21:31:10
    • 「それが落ちたりしなければ、問題はStreamではないとしか答えようがないです。」ってのは僕が「たまに落ちる」と書いたことへのレスでしょうか。もしそうだとしたらその件に関してTinoさんに何かを期待したり依頼をしてはいないです。 -- ひげぽん 2006-10-02 (月) 21:36:26
  • しつこくてごめんなさい。すっきりしたいだけなのでもう少しおつきあい下さい。SemaphoreもMutexも共有資源に対する排他的アクセスやロックを提供する概念だと理解しています。Semaphoreは共有資源の数Nがあって、N個の中で現在利用可能なリソースをレベルの上げ下げ(ひとつ使えば-1する)で管理するものです。で、MutexはSemaphoreの特殊な場合で共有リソースが1つしかなくて、リソースが使える/使えないの2通りの状態しかないものだと思っています。これが僕が理解しているSemaphore/Mutexの概念です。WindowsのAPIなどでSemaphoreとMutexが別れているのは、大抵の場合はMutexで足りるからあえてAPIを用意しているのはないかと僕は予想しています。つまりどちらも共有リソースへのアクセスを管理するしくみだと思うのですがいかがでしょうか。 -- ひげぽん 2006-10-02 (月) 17:32:58
    • (ageました)どんな回答を期待されているのか意味が分かりません。「Mutex=Binary Semaphore」という図式がWin32では成り立たない独自概念があるかどうかということですか?そのようなものはありません。私の説明の中でセマフォとMutexが入り乱れたのは、単に別々の用途に使うものが片方欠落してそのように見えただけということを説明しようとしていただけで、原理的な独自性などを書いているわけではありません。 -- Tino 2006-10-02 (月) 18:42:34
      • 「Mutexは排他処理で、セマフォはレベルの上げ下げなので、用途が違いますよね。」と書かれていたので私の認識しているSemaphore/Mutexと違いがあるのかどうかが知りたかったです。 -- ひげぽん 2006-10-02 (月) 21:30:34
      • 違わないと思います。 -- Tino 2006-10-02 (月) 21:58:23
    • お互いにまったく違う所を見ていたので話が噛み合わないのでしょう。私が「共有メモリとセマフォの合わせ技が使われる」と書きましたが、その後で「共有メモリとMutexによるメッセージの実装見てみました」とあったので、最初に書いた「セマフォ」とひげぽんさんが書いておられる「Mutex」(__mona_message_mutex)は別物であって、セマフォをMutexで代用しているわけではないということを書いたのでした。ここで書き方が悪くて「Win32のMutexは特殊でセマフォを兼ねる」のように伝わったため「Win32では何か違いがあるのでしょうか」と質問されたようですが、当初はそのことに気付かず、「MonaServerで使い分けている理由は何か?」という意味かと思い「用途が違いますよね。」と回答しました。ですがその後で私の書き方が悪く誤解を生んだということに気付いたので、「これは書き方が悪かったですね。」以下のことを追記しました。つまり私は、私が書いた解説とMonaServerの実装の違いのことを説明しようとしていたわけで、Mutexとセマフォの一般論の話をしているつもりはなかったので、話がそちらに行ったのは私が誤解を招いたためだと思い、話を戻そうとしていたのです。一般論に関しては特に食い違う点もなかったため、特に何も言いませんでした。以上、何か不満な点などありますでしょうか?>ひげぽんさん -- Tino 2006-10-02 (月) 22:00:52
      • 納得しました。いろいろとお手数お掛けしました。 -- ひげぽん 2006-10-02 (月) 22:36:32
  • あとストリームの実装上のコツとして、キューの中のデータを移動させないで始点をずらすというものがあります。これだけで伝わるでしょうか?意味不明なら説明します。 -- Tino 2006-09-28 (木) 10:00:28
    • あぁ。サイズが大きい場合は圧倒的にその方が有利ですね。あとでやっておきます。 -- ひげぽん 2006-10-02 (月) 17:36:50
  • それでメッセージとストリームのどちらがプリミティブかと言えば、ストリームであると考えています。メッセージにキューが使われていますが、そのキューをストリームとみなすわけです。メッセージでストリームをエミュレートすることは可能ですが、屋上屋の感が否めません。 -- Tino 2006-09-28 (木) 09:47:08
    • これは両方実装してみて個人的な結論を出したいなと思っています。 -- ひげぽん 2006-10-02 (月) 17:37:58
    • 何のことですか?標準入出力のことですか?ここではストリームの話だけをしているので、標準入出力は話が飛びすぎです。メッセージで標準入出力を実装するということであれば、何年も前に私がやっています。⇒議論/標準入出力/200405 -- Tino 2006-10-02 (月) 18:45:25
    • ここでは原理的にストリームはキューそのものだということを書いているだけです。その文脈で「両方実装してみて個人的な結論」というのは意味が分からないので、標準入出力に話が飛んでいるのかと思ったわけです。 -- Tino 2006-10-02 (月) 18:47:55
  • 仕様をまとめました。同じことをメッセージでやることは可能ですが、逆に、メッセージをストリームの上に実装することも可能だということに注目してください。もっともメッセージはカーネルレベルでサポートされており、タスクスイッチの面でも優遇されているので、それを敢えて完全にユーザー側に持って来る必要もないので、別々の仕組みとして扱うのが現実的だという認識です。 -- Tino 2006-09-27 (水) 14:59:39
    • 下にも書きましたが.mjtさんとも同じような議論になりました、結局メッセージとストリームはほとんど同じものですよね。使われるレイヤ・シチュエーションによって名前が変わっている印象です。例えばMonaのメッセージが任意サイズのバイト列をやりとりできるのであればストリームとほぼ同じですよね。(ストリームを否定する訳ではなくて似たものですよねという話です。) -- ひげぽん 2006-09-27 (水) 22:53:00
    • 一方で一方をエミュレートできるのですが、私がストリームとメッセージが決定的に違うと考えているのは、メッセージが明確にパケットの形態を取っていることです(下で述べたオブジェクトが入っているということ)。たとえばs->write("abc", 3);s->write("def", 3);と2分割するのとs->write("abcdef", 6);と一度で済ませるのとは等価ですが(この例は標準出力を意識しています)、メッセージだとパケットの壁(リニアではない)ができてしまいます。この差異には留意する必要があると思います。もちろんメッセージのデータだけを随時キューに溜めることで壁をなくすことができますが、このことが冒頭で述べたエミュレートです。 -- Tino 2006-09-28 (木) 08:57:15
      • はい。この違いも了解しています。(壁をなくす方法も含めて) -- ひげぽん 2006-10-02 (月) 17:36:03
  • 標準入出力を特別扱いしないというのは良い方向だと思います。汎用ストリームの話ですが、あえてMonAPI::Messageではなく汎用ストリームを作ることを薦めているのは一度にやりとりできる量とかメモリコピー回数を気にしての事でしょうか。 -- ひげぽん 2006-09-26 (火) 20:43:44
    • はいそうです、と言いたい所ですが、頭の中で想定している内容が同じかどうか分からないので、一応私の想定している仕様を上にまとめておきます。 -- Tino 2006-09-27 (水) 14:03:39
    • とりあえず詳しい解説は別途まとめるとして、ご質問に直接お答えすると:「一度にやりとりできる量」→はい、メッセージは粒度が桁違いに小さすぎます。「メモリコピー回数」→いいえ、メッセージの場合はタスクスイッチのオーバーヘッドの方が遥かに大きいので、メモリコピーは誤差程度です。 -- Tino 2006-09-27 (水) 14:06:28
    • 仕様のまとめありがとうございます。ストリームの基礎概念の認識はほとんど一致していますが完全に同一ではないようです。たぶんSICPの影響ですが、僕の場合Streamの中にはオブジェクトが格納できると思っていて、更に map とか fileter を長さ(要素数)が不確定のStream全体に対して適用できるみたいなのをイメージしていました。でも良く考えればこれはやりすぎ感が漂っていて、OSが提供するようなプリミティブなものではないのでTinoさん案のようなものが良い気がします。ストリームに関しては .mjt の人とも話して各自で何を以ってStreamといっているか違うもんだなと認識しました。 -- ひげぽん 2006-09-27 (水) 22:49:28
    • ここで私が念頭にしているのは標準入出力なので、オブジェクトを入れるとか関係ないプリミティブなものです。ただのバッファなのでオブジェクトを入れることは可能ですし、そのオブジェクトがMessageInfoであれば、メッセージと同じことになります。 -- Tino 2006-09-28 (木) 09:39:20
    • プリミティブであること、包含関係があることは理解しています。補足ありがとうございます。 -- ひげぽん 2006-10-02 (月) 17:35:11
  • 共有メモリとMutexによるメッセージの実装見てみました。MonaServer/Kernel/MonaMessage.hですね。勉強になりました。 -- ひげぽん 2006-09-26 (火) 20:43:31
    • ここでセマフォではなくMutexを使っているのは、Win32のメッセージループと両立させる必要があったため、Win32のメッセージ機構を通して通知だけは行う実装にしたためです。Win32のメッセージは通知だけでデータは共有メモリで管理しています。 -- Tino 2006-09-27 (水) 13:19:58
      • これは書き方が悪かったですね。もともとMutexは排他処理のためにセマフォと関係なく必要で、セマフォとして想定していた部分はWin32のメッセージループに回して存在しないので、Mutexだけが残ったようになったということです。つまりセマフォうんぬんで述べていることとMutexの用途は別で、Win32の都合でセマフォがMutexになったという意味ではないです。 -- Tino 2006-09-28 (木) 10:56:05
    • 完全に技術的興味なのですが、Mutex=Binary Semaphore だと思っているのですがWin32では何か違いがあるのでしょうか。 -- ひげぽん 2006-09-27 (水) 22:40:47
    • Mutexは排他処理で、セマフォはレベルの上げ下げなので、用途が違いますよね。これはWin32固有の概念ではなく、一般的な概念だと思っていました。たとえば上のwaitForRead()のようなものは、Mutexでは実現できないですよね。実際のread()やwrite()は排他なのでセマフォとは別にMutexが必要ですが(そのためMonaServerではMutexを用いている)、そこにセマフォは使わないですよね。 -- Tino 2006-09-28 (木) 09:42:17

MENU

now: 2

リンク


最新の20件
2018-05-03 2017-09-29 2017-04-25 2017-01-10 2016-12-11 2016-10-04 2016-08-14 2016-06-05 2016-05-29 2016-04-15 2015-12-28 2013-02-25 2013-02-21 2013-02-20 2013-02-12 2013-02-11 2013-02-10
最新の20件
2010-02-01 2010-01-31 2010-01-30 2010-01-29 2010-01-16

Counter: 3080, today: 1, yesterday: 0

リロード   新規 編集 凍結 差分 添付 複製 改名   トップ 一覧 検索 最終更新 バックアップ   ヘルプ   最終更新のRSS

Last-modified: 2008-03-28 (金) 15:48:02 (3763d);  Modified by mona
PukiWiki 1.4.6 Copyright © 2001-2005 PukiWiki Developers Team. License is GPL.
Based on "PukiWiki" 1.3 by yu-ji
Powered by PHP 5.2.17
HTML convert time to 0.131 sec.