Path: utzoo!mnetor!motto!ecijmm!robohack!woods
From: woods@robohack.UUCP
Newsgroups: comp.unix.questions
Subject: Re: Shared Mem, Msg queues, Semaphores  Code fragments wanted
Keywords: IPC XENIX shared memory segments interprocess communication
Message-ID: <1989Aug2.155906.18506@robohack.uucp>
Date: 2 Aug 89 15:59:06 GMT
References: <100@norsat.UUCP> <30715@ism780c.isc.com> <2313@auspex.auspex.com>
Reply-To: woods@robohack.UUCP (Greg A. Woods)
Organization: R. H. Lathwell Associates: Elegant Communications, Inc.
Lines: 32

In article <2313@auspex.auspex.com> guy@auspex.auspex.com (Guy Harris) writes:
>  >
>  > Of course, XENIX is not UNIX...
> 
> Yes, but it's derived from UNIX, and I'd expect that whoever put S5 IPC
> into it probably used as much of AT&T's code as possible.  The vendors
> of XENIX System V may even claim SVID compliance for that part of the
> system....

SCO put SysV IPC into Xenix, and from what they told me, the code went
into the kernel without change, except for the adjustment required to
SHM to make the pointer stuff work on segments for the i286.  AT&T had
to make the same changes for their 286 Unix, which you'll find in the
Bell Tech and Microport versions too.

I had a tiff with SCO a couple of years ago when I was writing some
code using IPC.  The problem turned out to be a difficulty in
configuring message queues within the restricted amount of memory
available in the i286 implementation such that deadlock would not
occur between processes allocating resources.  We finally came up with
a formula that worked, but the true solution is not to allow variable
length messages.

SysV IPC is a poor solution for a very common problem.  A better
solution is a good implementation of named pipes for message queues,
use a form of the /proc filesystem for shared memory, and use ordinary
files for semaphores.
-- 
						Greg A. Woods

woods@{robohack,gate,tmsoft,ontmoh,utgpu,gpu.utcs.Toronto.EDU,utorgpu.BITNET}
+1-416-443-1734 [h]	+1-416-595-5425 [w]	Toronto, Ontario;  CANADA