samperi@mancol.UUCP (Dominick Samperi) (03/08/88)
I've used the System V IPC facilities (shared memory and semaphores) on
an AT&T 3B2, and on an AT-compatible running Microport's UNIX, but had
some difficulty porting the programs to SCO Xenix. In the Xenix environment
a parent process can create a shared memory segment, and attach it, but
a forked child process gets an "invalid argument" error when it tries to
attach the same segment. The child process does indeed use the same segment
identifier that the parent did. (I'm using the AT&T-type IPC calls under
Xenix, not the native Xenix ones.)
Has anyone used the SCO Xenix IPC facilities? More generally, what kind
of applications have the IPC facilities (on any System V machine) been
used for? I haven't seen any applications programs that use them.
--
Dominick Samperi, Manhattan College, NYC
manhat!samperi@NYU.EDU ihnp4!rutgers!nyu.edu!manhat!samperi
philabs!cmcl2!manhat!samperi ihnp4!rutgers!hombre!samperi
(^ that's an ell) uunet!swlabs!mancol!samperidavidsen@steinmetz.steinmetz.UUCP (William E. Davidsen Jr) (03/16/88)
I added unix.wizards to this, because this is the type of esoteric subject which brings clarifying information from that group. In article <150@marob.MASA.COM> samperi@marob.UUCP (Dominick Samperi) writes: | In article <9844@steinmetz.steinmetz.UUCP> Bill Davidsen writes: | > | > SysV shared memory segments are inherited by the child, like any other | >open handle. If you open the segment and then do a fork, the child has | >access. If you fork and then open, the child will have to open, too. | | Perhaps you are talking about the Xenix-style IPC facilities here See original posting... I said SysV and meant it. | (sgget, etc.) which I no nothing about. When the SysV-style facilities | are used a forked child process must attach a shared memory segment Not true! | (using the segment identifier that the parent got when it created the | segment) before it can use it. That segment id is already in use by the child. What I said is that the child gets it from the parent. That's what happens. | This works fine on an AT&T 3b2 and under | Microport's System V/AT, but the child gets an "invalid argument" error | under SCO Xenix (same source code used on each system, compiled with | -Mle in the Xenix environment). I've learned something... I didn't know you could reopen a segment. Does it get a new address? | -- | Dominick Samperi, Manhattan College, NYC | manhat!samperi@NYU.EDU ihnp4!rutgers!nyu.edu!manhat!samperi | philabs!cmcl2!manhat!samperi ihnp4!rutgers!hombre!samperi | (^ that's an ell) uunet!swlabs!mancol!samperi When a child is forked it keeps open file, segments, and semiphores (as far as I can tell). Here is a program which assumes that what I say is correct. It runs on Xenix (286/386), 3B2-200, and the person who tested it for me says it runs on V/AT. It runs on Sun in SysV compile mode, but crashes at the end. I stand by my original statement in light of the evidence. Here's what it does: Process opens a shared segment Process opens a semiphore group Process forks Parent Child ================================================================ waits semiphore prints shared mem value sends semiphore waits semiphore changes shared mem value sends semiphore waits for child to die prints shared mem value (should be changed) terminates releases semiphore releases shared mem ================================================================ #include <sys/types.h> #include <sys/ipc.h> #include <sys/shm.h> #include <sys/sem.h> #include <stdio.h> #define xerror(m) if (errno) perror(m) extern int errno; main() { int key; /* shared memory key */ int far *ptr; /* address of shared memory */ int semi; /* semiphore key */ /* semiphore control buffers */ static struct sembuf set1 = {0,1,0}, /* set flag 1 */ wait1 = {0, -1, 0}, /* wait for flag 1 */ set2 = {1,1,0}, /* set flag 2 */ wait2 = {1,-1,0}; /* wait for flag 2 */ int pid; /* PID of child process */ /* get a portion of shared memory */ key = shmget((key_t)IPC_PRIVATE, 5*1024, 0700); printf("Parent attaching key %d\n", key); ptr = shmat(key, (char far *)NULL, 0); printf("Parent buffer at %08lx\n", ptr); if (errno) { perror("memory attach"); shmctl(key, IPC_RMID, (char far *)0); exit(1); } ptr[10] = 0x8228; if (key >= 0) { /* the shared memory is created, create a semiphore set */ semi = semget(IPC_PRIVATE, 2, 0700); printf("Parent semi id %d\n", semi); if (pid = fork()) { /* wait for the first signal */ semop(semi, &wait1, 1); ptr[10] = 0x1234; /* flag that the value has changed and wait for reread */ semop(semi, &set2, 1); semop(semi, &wait1, 1); while (wait() != pid); } else { printf(" Child buffer at %08lx\n", ptr); printf(" Child semi %d\n", semi); printf("Val: %04x\n", ptr[10]); /* flag that the child is ready */ semop(semi, &set1, 1); /* wait for the value to change */ semop(semi, &wait2, 1); printf("Val: %04x\n", ptr[10]); semop(semi, &set1, 1); #if 0 /* now release the semiphore */ semctl(semi, 0, IPC_RMID, 0); xerror("Child semi release"); #endif exit(0); } /* cleanup the semiphore and shared memory */ errno = 0; semctl(semi, 0, IPC_RMID, 0); xerror("Semi release"); shmdt(ptr); shmctl(key, IPC_RMID, NULL); xerror("Shared memory release"); } } -- bill davidsen (wedu@ge-crd.arpa) {uunet | philabs | seismo}!steinmetz!crdos1!davidsen "Stupidity, like virtue, is its own reward" -me
samperi@mancol.UUCP (Dominick Samperi) (03/17/88)
>In article <150@marob.MASA.COM> samperi@marob.UUCP (Dominick Samperi) writes: >| In article <9844@steinmetz.steinmetz.UUCP> Bill Davidsen writes: >| > >| > SysV shared memory segments are inherited by the child, like any other >| >open handle. If you open the segment and then do a fork, the child has >| >access. If you fork and then open, the child will have to open, too. I was told recently (by Amy Snader) that the SVID says that attached shared memory segments are indeed inherited by forked children, so you (and Xenix) are correct, "officially." It may also be true that it is not necessary for forked child processes to reattach under System V/AT, but I haven't checked this yet. On the other hand, I learned how to use the IPC facilities on a 3B2/300, with very little documentation and no examples, and I found by trial and error that the address that is returned to a parent process by shmat() is not valid for its forked children; they must explicitly attach the segment, using the shmid that was returned to the parent by shmget(). -- Dominick Samperi, Manhattan College, NYC manhat!samperi@NYU.EDU ihnp4!rutgers!nyu.edu!manhat!samperi philabs!cmcl2!manhat!samperi ihnp4!rutgers!hombre!samperi (^ that's an ell) uunet!swlabs!mancol!samperi
allbery@ncoast.UUCP (Brandon Allbery) (03/24/88)
As quoted from <9947@steinmetz.steinmetz.UUCP> by davidsen@steinmetz.steinmetz.UUCP (William E. Davidsen Jr): +--------------- | In article <150@marob.MASA.COM> samperi@marob.UUCP (Dominick Samperi) writes: > (statement that processes don't inherit shm segments after fork() in SysV) | | Perhaps you are talking about the Xenix-style IPC facilities here | See original posting... I said SysV and meant it. | | (sgget, etc.) which I no nothing about. When the SysV-style facilities | | are used a forked child process must attach a shared memory segment | Not true! +--------------- From the manual page for fork(2), System V Release 2: "...the child process inherits the following attributes from the parent process: ... all attached shared memory segments ..." I'll check the Xenix manuals at work tomorrow and see what they say, but remember that Xenix 5 is schizoid about shared memory... no telling from my end whether System V shared memory is implemented in terms of Xenix shared data or vice versa or if they're separate facilities (but they *do* share a global pte table, according to the Xenix V/386 manual at work!). -- Brandon S. Allbery, moderator of comp.sources.misc {well!hoptoad,uunet!hnsurg3,cbosgd,sun!mandrill}!ncoast!allbery