私はmmap
ファイルの読み取りに使用することを検討しており、それがどれほど移植性があるか疑問に思っていました。Linux プラットフォームで開発していますが、自分のプログラムを Mac OS X と Windows で動作させたいと考えています。
mmap
これらのプラットフォームで動作していると推測できますか?
mmap()
関数は POSIX 呼び出しです。MacOS X (および Linux、HP-UX、AIX、Solaris) で問題なく動作します。
問題の領域は Windows です。_mmap()
POSIX 'compatibility' サブシステムに呼び出しがあるかどうかはわかりません。そこにある可能性は高いですが、名前の先頭にアンダースコアが付いた名前になります。これは、Microsoft が名前空間に対して別の見方をしてmmap()
おり、ユーザーが POSIX 機能を要求したとしても、ユーザーの名前空間に侵入することを検討しているためです。別の SO の質問 ( vs reading blocks )で、代替の Windows インターフェイスの定義とMapViewOfFile()
パフォーマンスに関する議論を見つけることができます。mmap()
32 ビット システムで大きなファイルをマップしようとすると、ファイル全体をメモリに割り当てるのに十分な連続した領域がなく、メモリ マッピングが失敗することがあります。うまくいくと思い込まないでください。失敗した場合のフォールバック戦略を決定します。
大きなファイルの大きなビットをアドレス空間にマッピングすることに依存している場合、ファイルの読み取りに mmap を使用することは移植性がありません。多くの場合、1G マッピング用です。
メモリ マップ ファイルの原則はかなり移植性がありますが、Windows には mmap() がありません (ただし、MapViewOfFile() のようなものは存在します)。Python mmap モジュールの c コードをのぞいて、さまざまなプラットフォームでどのように機能するかを確認できます。
UNIXのメモリマップドIOは、SIGSEGV / SIGBUSになる可能性があるため、インタラクティブアプリケーションには使用できないと考えています(ファイルが他のプロセスによって切り捨てられた場合)。setjmp / longjmpのような病気の「解決策」を無視すると、SIGSEGV/SIGBUSを取得した後にプロセスを終了する以外にできることはありません。このようなシグナルを例外に変換する新しいG++機能は、主にApple OSを対象としているようです。説明には、このG ++機能のランタイムサポートが必要であり、このG++機能に関する情報がどこにも見つからないことが記載されているためです。20年以上がUNIXに移行して以来、Windowsで見られるような構造化された例外処理が行われるまで、おそらく2、3年待たなければなりません。