Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!killer!vector!rpp386!pigs!haugj From: haugj@pigs.UUCP (Joe Bob Willie) Newsgroups: comp.unix.xenix Subject: Re: Test SCO Xenix IPC reliability Summary: really about *nix scheduling Keywords: ipc reliability Message-ID: <376@pigs.UUCP> Date: 27 Aug 88 19:35:54 GMT References: <22012@neabbs.UUCP> <5786@rpp386.UUCP> <114@telmail.UUCP> Reply-To: haugj@pigs.UUCP (Joe Bob Willie) Organization: Big "D" Oil and Gas Lines: 27 In article <114@telmail.UUCP> root@telemail.UUCP (Richard Ronteltap) writes: >Because loc[0] was initialised to 0, the child process waits if it happens >to get to the 'while' loop first. The parent process passes the loop, prints >TICK, changes *loc to 1 and signals the child process. AT THIS INSTANT, i.e. >BEFORE the parent reaches pause(), the scheduler transfers control to the >child process. (btw is this possible?) what appears to have been happening is that if the parent ran all the way to the kill() call before the child called signal(), the child dies from the signal and the parent waits in pause() for the dead child to kill the parent(). this can only happen with the parent because of setting *loc = 0. if the CHILD beat the PARENT through the loop after being kill()'d to kill() the parent BEFORE the parent executes the pause(), the parent waits in pause() forever for a signal which has already been delivered, along with the child who is waiting for the parent. it is possible for the scheduler to pick any runnable process at just about any time (well, only certain times, but it appears suitably random to the process) to run, and may suspend any running process to do so. the only restriction on putting processes to sleep is that a process running in system space can't been involuntarily put to sleep. it must call sleep() itself. -- =-=-=-=-=-=-=-The Beach Bum at The Big "D" Home for Wayward Hackers-=-=-=-=-=-= Very Long Address: John.F.Haugh@rpp386.dallas.tx.us Very Short Address: jfh@rpp386 "ANSI C: Just say no" -- Me