peter@stca77.stc.oz (Peter Jeremy) (09/05/88)
In article <530@vector.UUCP> chip@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@stca77.stc.oz Alcatel-STC Australia ...!munnari!stca77.stc.oz!peter 41 Mandible St peter%stca77.stc.oz@uunet.UU.NET ALEXANDRIA NSW 2015