おはよございます。
またはずしましたか・・・(^^;

> 元メールのように、後から強引に伸ばしたマッピングエリアに対しても
> ほかのマッピングと共有している部分(メールの例では先頭100バイト)
> に関しては(きっちり排他処理を行っていれば)
> 通常のマッピングと同様に読み書きができて、メモリ共有手段としても
> 扱えるのか?
> ということだったのですが。。。
なるほど。

たとえば、普通にオープンするファイルだった場合に他のプロセスがファ
イルのサイズを変えると、別のオープン済みのプロセスは変化したサイズ
までファイルポインタをシークできるはずですよね。
これと同じようなメカニズムではないでしょうか?
ファイルマッピングオブジェクトとはいえ、プログラムから直接ファイル
にアクセスするのではなく、OS内部のキャッシュが実施されているはずで
す。なので、一方のプロセスではたぶん範囲外だろうあたりのオフセット
を指定されてもキャッシュ更新時に同期を取るだろうから、ご要望のこと
はOSとして「できなければならない」ことではないかと。

> うーむ。
> ページファイルではだめだった私のサンプルがおかしいかのせいもあるので
> また、ちょっと調べてみます。
なるほど。第一引数NULLだったらうまくいかなかったということですね?
この場合、ファイルとしてというより共有メモリとしての機能ですし、
うまくいくと思うんだけどなぁ・・・

増殖させる大きさをOSのキャッシュサイズより大きくしたりして実験すると
可・不可の判断ができるような気がしますが・・・σ(^_^)はできると思いま
すね。
#時間がないのでテストできませんが・・・

Win32だと、ネットワーク越えのプロセス間では保証していないとかいう
ことがどこかに書いてあったような・・・あれは別の話だったかな・・・
(遠い目)

是非結果を教えてくださいませ。
#でもって、σ(^_^)が間違っていた場合は、ごめんなさい。(^^;
_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ Y.Uchiyama _/_/
_/private:
_/  HANDLE ゆーち;
_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/