Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!ames!elroy!gryphon!vector!chip
From: chip@vector.UUCP (Chip Rosenthal)
Newsgroups: comp.unix.xenix
Subject: Re: Test SCO Xenix IPC reliability
Message-ID: <539@vector.UUCP>
Date: 3 Sep 88 19:44:56 GMT
References: <22012@neabbs.UUCP> <166@ispi.UUCP> <530@vector.UUCP> <6141@rpp386.Dallas.TX.US>
Reply-To: chip@vector.UUCP (Chip Rosenthal)
Organization: Dallas Semiconductor
Lines: 16

In article <6141@rpp386.Dallas.TX.US> jfh@rpp386.Dallas.TX.US (The Beach Bum) writes:
>In article <530@vector.UUCP> chip@vector.UUCP (Chip Rosenthal) writes:
>>is it realistic for the service requestor to know
>>the PID of the service server?
>if you are using semaphores, then i doubt it.  for shared memory, why not?

I guess you are right.  Probably do something like have the service requestor
attach to the segment, read out the PID of the service provider, leave the
request, and then signal the provider that a request is awaiting.

You wouldn't be beating on it as hard as the test case did, so the chance
of signal races is reduced.  The only limitation I see is that the requestor
needs to be the same UID as the provider to send the signal.
-- 
Chip Rosenthal     chip@vector.UUCP | I've been a wizard since my childhood.
Dallas Semiconductor   214-450-0486 | And I've earned some respect for my art.