Are pointers in a shared memory segment valid for a different process?
Ray Ward
ray at ctbilbo.UUCP
Sat Aug 25 09:23:24 AEST 1990
In article <838 at qusunc.queensu.CA>, kelley at qucis.queensu.CA (Todd Kelley) writes:
> Suppose that process A and process B both have one particular shared
> memory segment attached to their respective address spaces with shmat().
>
> If the base of the shared memory segment is at AAA0 in A's address space,
> and at BBB0 in B's address space (for example), in order for
> B to access the strings in the array, B would need to add (AAA0-BBB0) to
> each of the pointers in the array to make them point at the strings in
> B's address space.
>
> Is this wrong? If not, is there an accepted way to map addresses back
> and forth between address spaces?
You are correct. If the shared memory segment maps into different addresses
in the two processes address spaces, pointers are invalid between the two
processes.
The first response most programmers have to this problem is to store
offsets somewhere. This is cumbersome, at best, and has never been
required in any system I have seen.
Another approach, sometimes feasible, is to store only non-pointer data
in the shared memory area. This is rather constricting for C programmers.
The most usual approach is to pick an address at which to map in the
shared memory segment in *both* programs. If you pick an address that
is considerably larger than the larger of the two programs is likely to
grow, no further maintainance is required. Both programs can place
pointers in the shared memory area because both programs have mapped the
shared memory segment to the same address. (For portability it is best to
set the SHM_RND flag to allow architectures that require segment boundaries
to do their own thing and tell you where they *really* mapped in the
segment.)
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Ray Ward Email: uunet!ctbilbo!ray
Voice: (214) 991-8338x226, (800) 331-7032 Fax : (214) 991-8968
=-=-=-=- There _are_ simple answers, just no _easy_ ones. -- R.R. -=-=-=-=
More information about the Comp.unix.wizards
mailing list