Test SCO Xenix IPC reliability
The Beach Bum
jfh at rpp386.Dallas.TX.US
Fri Sep 2 23:42:35 AEST 1988
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
More information about the Comp.unix.xenix
mailing list