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" -mesamperi@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.