IPC Keys (was Re: Test SCO Xenix IPC reliability)
Peter Jeremy
peter at stca77.stc.oz
Mon Sep 5 11:20:25 AEST 1988
In article <530 at vector.UUCP> chip at vector.UUCP (Chip Rosenthal) writes:
>In a multi-processing package, it is reasonable to fix the IPC service
>id number to a known value.
This depends upon the environment in which the package is going to run.
Iff you are producing a turn-key system, or can guarantee that the system
will not be running any other packages that use IPC, then fixed numbers
are ok. Otherwise you need to use something else...
> (Grrrr...I've heard the performance arguments.
>I *still* wish IPC mapped to a filesystem name rather than using a stupid,
>magic ID number.)
Its not quite as bad as this. Have a look at STDIPC(S). You pass ftok()
a filename and an id byte, and it returns an IPC key (based on the id byte
and the device name/inode number of the file). This means that you have
a choice as to whether you use hard coded numbers, or filesystem name type
keys.
> But, is it realistic for the service requestor to know
>the PID of the service server?
This approach is used by QNX. All the PID of the server would be in
this case is a key, no different to the keys returned by the {ipc}get()
functions in SysV. _Finding_ the PID of a process unrelated to you is
virtually impossible - a new system call would probably have to be
provided to allow the requester to locate the server. There are two
major disadvantages. One - you can only have _one_ server process for a
particular task (whilst this is the norm, if is _very_ difficult to work
around if you need to). Second, it gets a bit messy to organise
recovery if the server has to be restarted for any reason - each client
process must detect that the server has died and get the new server's
PID.
--
Peter Jeremy (VK2PJ) peter at stca77.stc.oz
Alcatel-STC Australia ...!munnari!stca77.stc.oz!peter
41 Mandible St peter%stca77.stc.oz at uunet.UU.NET
ALEXANDRIA NSW 2015
More information about the Comp.unix.xenix
mailing list