Path: utzoo!attcan!uunet!peregrine!elroy!gryphon!vector!rpp386!jfh
From: jfh@rpp386.UUCP (The Beach Bum)
Newsgroups: comp.unix.xenix
Subject: Re: Test SCO Xenix IPC reliability
Message-ID: <5786@rpp386.UUCP>
Date: 24 Aug 88 19:48:02 GMT
References: <22012@neabbs.UUCP>
Reply-To: jfh@rpp386.UUCP (The Beach Bum)
Organization: HASA, "S" Division
Lines: 39

In article <22012@neabbs.UUCP> richard@neabbs.UUCP (RICHARD RONTELTAP) writes:
>[ Tested the ticktock.c program ]
> 
>Firstly: 286 Xenix'ers should compile the test program of J.F. Haugh
>(II?, come on!) to large model with the -Ml switch.

[ yes, my uncle was john f. haugh.  he wasn't married when i was born
  so it was assumed he would remain childless.  my legal name is jfh2. ]

>When the program is started the first time only one TICK/TOCK is
>printed. When it is started the second time. TICK/TOCK is infinitely
>printed.

[ ... ]

>The second time scheduling is different because the shared memory
>doesn't have to be created.

this program should work regardless of scheduling.  on the first entry
into child() the busy loop will be executed because loc[0] was set to
zero prior to the fork.  the signal handler was set prior to entry to
child (but should have been set before the fork() - stupid me).

if parent() executes the kill() call before the child() executes the
signal() call, then you should have seen TICK ... with a hang forever.
the fix is to move the signal() call to before the fork().  if ... TOCK
is printed then signal() has been called.

>All this is rather far fetched, but the only explenation I can think
>of. At least no panic's or core dumps.

no, it is very plausible if only TICK ... was printed.  this is why
concurrent programming is such a joy and volatile variables have to
be treated specially.  because this ain't easy sh*t.
-- 
John F. Haugh II (jfh@rpp386.UUCP)                           HASA, "S" Division

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