議論/メッセージ/案1(ひげぽん)

ボツになりました。

概要・思い †

• ひげぽんの提唱するプロトタイプ(たたき台になればいいなと言う程度)
• カーネルがサポートするのはメッセージキューを持たない同期メッセージのみ
• キューが必要な場合はユーザーライブラリが実装する

メッセージI/F †

• SEND
• REPLY
• RECEIVE

send/reply方式についての考察 †

• 考えてみました。皆さんと認識あっていますか？＞Gakuさん ＞shadowさん ＞Yui_Nekoさん > Tinoさん --ひげぽん

1. スレッドAはスレッドBにsendする
   1. Bがメッセージ受信可能ならば
      1. Bのメッセージバッファにメッセージをセットする
      2. Aはブロックされる
   2. Bがメッセージ受信可能でないとき
      1. Aはブロックされる
      2. Bが受信可能になりしだいメッセージをセット後またブロックされてる。事前に設定された時間でタイムアウトになるとAのブロックは解除される
2. スレッドBはreceiveする
3. BはAにreplyする
   1. Aはsendの戻り値としてreply結果を得る

活発なご意見 †

• 用語の扱いが既知のものと違っていると無用な誤解が生じるという懸念があったので、書きました。 -- Tino 2004-05-24 (月) 22:40:28
  • お気遣いありがとうございます。> Tinoさん。MonaでMonAPIとMonaGUIを実装された立場からみて上記のようなメッセージ仕様であった場合どうでしょうか?(デメリット・懸念点等)-- ひげぽん
  • この仕様におけるreplyの実体はsendなので原理的には別物ではないですし、よりプリミティブなものだけをベースに含めるという立場からは、高級過ぎるという懸念があるかもしれません。 -- Tino
• 早速のご意見ありがとうございます。その件承知しております。 -- ひげぽん 2004-05-24 (月) 22:37:34
• Windowsではsendは同期で実行されるため、処理先の関数（別プロセスであっても）の戻り値が直接sendに返されます。そのためreplyはメッセージを使わずに実現されています。Monaのような非同期の送信はpostと言って別扱いです。参考まで。 -- Tino 2004-05-24 (月) 22:31:50

MENU

• はじめに
• スクリーンショット
• ドキュメント
• ダウンロード
• スペック
• プロジェクトマップ
• BayGUI(ADK)
• MonAPI
• Mona(0.4.0)
• 質問所(パッチ)
• デバッグ技法
• コミュニティ
• 連絡帳
• 議論
• 提案
• ご意見箱
• スレッド(現行)
• Reading作業ログ

リンク

• ひげぽんはてなダイアリー
• Higepon blog(英語)
• 和製OS情報

最新の20件

最新の20件