[comp.unix.xenix] IPC facilities

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!samperi

davidsen@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" -me

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

wes@obie.UUCP (Barnacle Wes) (04/02/88)

In article <7541@ncoast.UUCP>, allbery@ncoast.UUCP (Brandon Allbery) writes:
>                                                           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!).

According to Amy Snader of SCO, the Xenix-style shared data in Xenix V
is implemented on top of *the System V shared memory system.*  Given
this, System V code should run on Xenix without a hitch.  Amy's a tech
type, not a salesweenie; she should know.

	Wes Peters

(Hi Amy!  You *knew* better than to send that message, didn't you?!?!?)
-- 
    /\              -  "Against Stupidity,  -    {backbones}!
   /\/\  .    /\    -  The Gods Themselves  -  utah-cs!utah-gr!
  /    \/ \/\/  \   -   Contend in Vain."   -  uplherc!sp7040!
 / U i n T e c h \  -       Schiller        -     obie!wes