次に示すプロセス間通信 (IPC) プリミティブは、従来どおり 64 ビットプロセスと 32 ビットプロセスとの間で動作します。
システム V IPC プリミティブ、たとえば shmop(2)、semop(2)、msgsnd(2)
共有ファイル上の mmap(2)
プロセス間の pipe(2)
プロセス間の door_call(3X)
xdr(3N) に説明されている外部データ表現を使用した、同じあるいは異なるマシン上のプロセス間の rpc(3N)
これらのすべてのプリミティブは、32 ビットプロセスと 64 ビットプロセスとの間の通信を可能にしますが、プロセス間で交換されているデータがそれらすべてのプロセスで正しく解釈されることを、明確な手順によって確認する必要がある場合があります。たとえば、long
型の変数を含む C データ構造体で記述されるデータを 2 つのプロセスが実際に共有するには、32 ビットプロセスがこの変数を
4 バイト量とみなし、64 ビットプロセスはこの変数を 8 バイト量とみなすということを認識する必要があります。
この相違を取り扱う 1 つの方法は、データが正確に同じサイズで、両プロセスで意味があることを確認することです。データ構造が int32_t
や int64_t
のような固定幅型を使って構成されていることを確認してください。
システムで提供される派生型に対応する派生型の一群が <sys/types32.h> にあります。これらの派生型は、32 ビットシステムの基本型と同じ符号、同じサイズですが、ILP32 および LP64 のコンパイル環境でサイズが変わらないように定義されています。
32 ビットプロセスと 64 ビットプロセスとの間でポインタを共有するのは、さらに困難です。まずポインタのサイズが異なるということがあります、またそれ以上に重要なことは、既存の
C の使用法に 64 ビット整数 (long long
) はあるが、64 ビットポインタに等価なものは 32 ビット環境にはない、ということです。64
ビットプロセスが 32 ビットプロセスとデータを共有できるようにするためには、32 ビットプロセスは共有データのうち、4G バイトまでだけを一度に「見る」ことができるという点に注意が必要です。
XDR ルーチンの xdr_long(3N) は問題と思われるかもしれません。しかし、これは既存のプロトコルとの互換性を持たせるために従来どおり
32 ビットとして取り扱われます。64 ビットバージョンのルーチンが 32 ビットに格納できない long
値をコード化するように要求された場合、そのコード化処理は失敗します。