Test SCO Xenix IPC reliability

[The Beach Bum]

In article <530 at vector.UUCP> chip at vector.UUCP (Chip Rosenthal) writes:
>A couple of comments and questions about the IPC test program -- the
>shared memory version, not the message queue one.
>
>Why is loc being set here?  One of the first actions in main() is:

the code was old and moldy from other uses and i didn't clean it
up.

>I don't understand the purpose of "zero".  Can anybody help out?

originally it was there for paranoia.

>Second, wouldn't it be more realistic to drop the pause() and just do
>a polling loop?  I would change:

yes, the original did do polling, but the tick ... ... tock's came
at one second intervals as each processes quantum expired.  [ this
is only true on an idle system where no pre-emption is occuring. 
more or less ;-) ]  putting in the signals sped things up, so i
posted it.  i didn't ever expect it to fall under close scrutiny.

>In a multi-processing package, it is reasonable to fix the IPC service
>id number to a known value.  (Grrrr...I've heard the performance arguments.
>I *still* wish IPC mapped to a filesystem name rather than using a stupid,
>magic ID number.)  But, is it realistic for the service requestor to know
>the PID of the service server?

i suppose it would depend on the implementation.  if you are using
semaphores, then i doubt it.  for shared memory, why not?
-- 
John F. Haugh II (jfh at rpp386.Dallas.TX.US)                   HASA, "S" Division

    "If the code and the comments disagree, then both are probably wrong."
                -- Norm Schryer