Test SCO Xenix IPC reliability

[The Beach Bum]

In article <22012 at neabbs.UUCP> richard at 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 at rpp386.UUCP)                           HASA, "S" Division

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