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.
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/08/88)
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 have used the shm stuff without too much trouble, but the semiphores
really have me going. I can make them work as traditional semiphores,
notify and wait model, but when I start using the counts, I get some
funny results.
I'm still working on this, and will try it in a number of systems to
be sure the bug isn't in Xenix.
--
bill davidsen (wedu@ge-crd.arpa)
{uunet | philabs | seismo}!steinmetz!crdos1!davidsen
"Stupidity, like virtue, is its own reward" -mevandys@hpindda.HP.COM (Andy Valencia) (03/09/88)
We used it to connect together the two parts of our SNA product. The "nucleus" part, which handles the SDLC link, always runs. When you want an SNA terminal (327x type), you run the "PS (Presentation Service)". It talks over System-V messages. But because message IDs aren't file descriptors (thanks, AT&T), and because we don't get select() in any case, you always have to follow a message write with a signal, when writing from Nuc. to PS (because PS blocks on keyboard), and you don't send one PS to Nuc., because the Nuc. blocks on the message port--the SDLC driver signals when it gets something. In case you haven't gathered it from the above, it takes a reasonable amount of dancing about to get "real life" products running with it. I imagine that having multiple threads of execution will mitigate this, as you can then just block a thread on each resource. Andy Valencia vandys%hpindda.UUCP@hplabs.hp.com
samperi@marob.MASA.COM (Dominick Samperi) (03/10/88)
In article <9844@steinmetz.steinmetz.UUCP> davidsen@crdos1.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. > >-- > bill davidsen (wedu@ge-crd.arpa) > {uunet | philabs | seismo}!steinmetz!crdos1!davidsen >"Stupidity, like virtue, is its own reward" -me Perhaps you are talking about the Xenix-style IPC facilities here (sgget, etc.) which I no nothing about. When the SysV-style facilities are used a forked child process must attach a shared memory segment (using the segment identifier that the parent got when it created the segment) before it can use it. 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). -- 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
tim@doug.UUCP (Tim J Ihde) (03/10/88)
In article <335@mancol.UUCP>, samperi@mancol.UUCP (Dominick Samperi) writes: > 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. I've got a set of simple programs that I wrote to allow shell scripts to interact via semaphores. They provide for things like mksem (create a semaphore), rmsem (remove a semaphore), p, and v. This allows shells to safely access a resource. While I originally developed these programs on System V, they compiled and ran OK on Xenix, as I recall - although I probably didn't do any extensive testing. I'm sure processes blocked and waited when they were supposed to. As for other uses, I've used shared memory to hold frequently accessed information (like a database schema or a passwd file). I know the UN*FY database uses shared memory for record locking. I've also used messages for detailed control of child processes. These are all under System V, I haven't tried this kind of thing under Xenix yet. tim -- Tim J. Ihde ihnp4!ctsmain!doug!tim (201) 560-6808 This disclaimer intentionally left blank.
davidsen@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