これを回避するには、メモリ上にある管理情報エリアを、HDD上にファイルとして持ち、それを使用する以外にはない。
しかし、今の管理情報内には双方向のメモリポインタを保持したチェーン構造となっており、ファイルで完全管理を行うには大幅な修正(根本的な見直し)が必要となり、得策ではないのですよ。
で、いろいろ考えていて行き着いたのが、メモリマップドファイルという仕組み。
void *mmap(void *addr, size_t len, int prot, int flags, int fildes, off_t off);
これを利用すると、戻り値として得られる void * をメモリ先頭として扱うことができるので、ポインタを意識した既存の処理との親和性もよく、ファイルなので電断処理の対応もやりやすい筈。
mmap()
システムコールを使用すると、 read()/write()
を使わなくてもアドレス空間を操作することでリソースにアクセスできる。たとえば、以下のような lseek の記述はfd = open(...);
lseek(fd, some_offset)
read(fd, buf, len)
/* use data in buf */
mmap では以下のようになる。
fd = fopen(...);
address = mmap((caddr_t)0, len, PROT_READ, MAP_SHARED, fd, some_offset);
/* use data at address */
そしてメモリにマッピングされた内容と実際のファイルとの同期を取るには msync()
関数を使用するということで、SRAM時代やっていたsyncがそれに相当するので、それもいいかも。
int msync(void *addr, size_t len, int flags);問題は今回のターゲットプラットフォームでサポートされているのか?だけど、明日調べてみよう。
0 件のコメント:
コメントを投稿
注: コメントを投稿できるのは、このブログのメンバーだけです。