Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!killer!vector!rpp386!jfh
From: jfh@rpp386.Dallas.TX.US (The Beach Bum)
Newsgroups: comp.unix.xenix
Subject: Re: Test SCO Xenix IPC reliability
Message-ID: <6141@rpp386.Dallas.TX.US>
Date: 2 Sep 88 13:42:35 GMT
References: <22012@neabbs.UUCP> <166@ispi.UUCP> <530@vector.UUCP>
Reply-To: jfh@rpp386.Dallas.TX.US (The Beach Bum)
Organization: HASA, "S" Division
Lines: 35

In article <530@vector.UUCP> chip@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@rpp386.Dallas.TX.US)                   HASA, "S" Division

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