dave@norsat.UUCP (Dave Binette) (07/28/89)
An upcoming project requires some efficient interprocess communications
to be developed using XENIX 386's V2.3.1
Since my working knowledge of IPC's is a small subset of total ignorance,
I could really use (and appreciate) code fragments incorporating any of
the following:
msgctl(S) msgget(S) msgop(S)
semctl(S) semget(S) semop(S)
shmctl(S) shmget(S) shmop(S)
ipcs(C) ipcrm(C)
Exercises and "just-playing-around-with" type code would be wonderfull.
Formally correct code would be ideal.
Dont be shy about "sloppy" code though, its just between You and Me, and
I'll rework anything I receive to suit my own twisted idea of apropos'
If there is interest in this project i'll be happy to post a set of
commented exercises using some or all of these functions as a result
of my learning process.
--
uucp: {uunet,ubc-cs}!van-bc!norsat!dave | 302-12886 78th Ave
bbs: (604)597-4361 24/12/PEP/3 | Surrey BC CANADA
voice: (604)597-6298 (Dave Binette) | V3W 8E7patrick@scrooge.ism.isc.com (Patrick Curran) (08/01/89)
In article <100@norsat.UUCP> dave@norsat.UUCP (Dave Binette) writes: >An upcoming project requires some efficient interprocess communications >to be developed using XENIX 386's V2.3.1 > >Since my working knowledge of IPC's is a small subset of total ignorance, >I could really use (and appreciate) code fragments incorporating any of >the following: >msgctl(S) msgget(S) msgop(S) >semctl(S) semget(S) semop(S) >shmctl(S) shmget(S) shmop(S) >ipcs(C) ipcrm(C) > The "AT&T UNIX System V/386 Programmer's Guide" has a whole chapter on IPCs. This includes full listings of test programs that exercise all aspects of the IPC system calls. I haven't tried them, but they look pretty good. I think you'll find them a great help. Of course, XENIX is not UNIX... Patrick Curran (patrick@ism780c.isc.com) (uunet!ism780c!patrick) INTERACTIVE Systems Corp, Santa Monica, CA. (213) 453-8649
todd@stiatl.UUCP (Todd Merriman) (08/01/89)
>I could really use (and appreciate) code fragments incorporating any of >the following: >msgctl(S) msgget(S) msgop(S) >semctl(S) semget(S) semop(S) >shmctl(S) shmget(S) shmop(S) >ipcs(C) ipcrm(C) "Advanced Unix Programming" by Marc J. Rochkind Prentice-Hall, Inc. Englewood Cliffs, NJ 07632 ...!gatech!stiatl!todd Todd Merriman * 404-377-TOFU * Atlanta, GA
guy@auspex.auspex.com (Guy Harris) (08/02/89)
(This is generic UNIX stuff - generic, at least, to systems that have picked up S5 IPC - so we move it here to "comp.unix.questions"....) >The "AT&T UNIX System V/386 Programmer's Guide" has a whole chapter on >IPCs. This includes full listings of test programs that exercise all >aspects of the IPC system calls. I haven't tried them, but they look >pretty good. I think you'll find them a great help. > >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....
gwyn@smoke.BRL.MIL (Doug Gwyn) (08/02/89)
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, ... XENIX is too UNIX! At least, in its current incarnation it is supposed to be. Remember the AT&T/MicroSoft agreement to merge XENIX with UNIX System V and call the result UNIX System V Release 3.2? It was the merger right before the SunOS/SysV one.
steinar@fdmetd.uucp (Steinar Overbeck Cook) (08/02/89)
I suggest you read the book "Advanced UNIX Programming" by Marc J. Rochkind. It explains IPC very good, and contains some sample programs which utilises shared memory, semaphores and message queues. -- Steinar Overbeck Cook, Fellesdata a.s, P.O. Box 248, 0212 OSLO 2, NORWAY Phone : +47 2 52 80 80 Fax : +47 2 52 85 10 E-mail : ...!mcvax!ndosl!fdmetd!steinar or steinar@fdmetd.uucp <The opinions expressed, if any, do not represent Fellesdata a.s>
woods@robohack.UUCP (08/02/89)
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
karl@ddsw1.MCS.COM (Karl Denninger) (08/03/89)
In article <2313@auspex.auspex.com> guy@auspex.auspex.com (Guy Harris) writes: >(This is generic UNIX stuff - generic, at least, to systems that have >picked up S5 IPC - so we move it here to "comp.unix.questions"....) > > >The "AT&T UNIX System V/386 Programmer's Guide" has a whole chapter on > >IPCs. This includes full listings of test programs that exercise all > >aspects of the IPC system calls. I haven't tried them, but they look > >pretty good. I think you'll find them a great help. > > > >Of course, XENIX is not UNIX... Xenix is darn close to Unix when it comes to this stuff. We have code which works without change on both SCO Xenix V/386 2.3 and the AT&T-derived SVR3.2.... No problems noted so far..... our use includes semaphores as well as (sometimes large) shared memory segments.... all is well... In fact, one of these is a multiuser game which has been posted to alt.sources before (cosmos); the entire game grid is a sharable segment! The only Xenix-specific code in there is a "nap" (short sleep); I understand that current Unix releases (3.2) have the same functionality available too, so it ought to work there as well. -- Karl Denninger (karl@ddsw1.MCS.COM, <well-connected>!ddsw1!karl) Public Access Data Line: [+1 312 566-8911], Voice: [+1 312 566-8910] Macro Computer Solutions, Inc. "Quality Solutions at a Fair Price"
guy@auspex.auspex.com (Guy Harris) (08/04/89)
>SysV IPC is a poor solution for a very common problem. A better >solution is a good implementation of named pipes for message queues, I think S5R4 will have a way of attaching a stream to a file name, so that users opening the file, in effect, establish a connection to the process on the other end of the stream; I think that, unlike named pipes, this works similarly to the "connect" socket call, so each connection gets a unique descriptor in the server, so it can more easily keep the conversations separate. The descriptor also refers to a stream, so that e.g. message boundaries can be preserved. >use a form of the /proc filesystem for shared memory, Uhh, why "/proc"? That seems like a poor solution, too, especially considering that the standard form won't work - you have to be the owner of a process, or the super-user, to open its "/proc" file (for obvious reasons!). Instead, what you want is to have some way of using a plain file as the item at which the processes rendezvous; this can be done in S5R4 by having both processes "mmap" the file MAP_SHARED, which maps the file into their address space such that if you modify a page in the mapped region it ends up modifying the file.