Path: utzoo!attcan!uunet!mcvax!hp4nl!telmail!neabbs!richard
From: richard@neabbs.UUCP (RICHARD RONTELTAP)
Newsgroups: comp.unix.xenix
Subject: Re:Test SCO Xenix IPC reliability
Message-ID: <22012@neabbs.UUCP>
Date: 23 Aug 88 01:46:09 GMT
Organization: NEABBS multi-line BBS +31-20-717666 (12x), Amsterdam, Holland
Lines: 31

[ 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.
 
Welllll, I ran the test program on XENIX /386 2.2.1 and 2.2.3 with the
same results.
 
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.
 
I think what happens is:
When the shared memory is created, and the parent process has printed
TICK, the context is switched to the child process right after the
'signal' command and just before the 'pause' command. When the child
now signals the parent, the signal is caught and the parent goes the
the next command: pause(), and waits for ever!
 
The second time scheduling is different because the shared memory
doesn't have to be created.
 
 
All this is rather far fetched, but the only explenation I can think
of. At least no panic's or core dumps.
 
Can anyone else post experiences?
Maybe Mr Chapman from SCO Kernel development can comment on this?
 
Richard
(...!mcvax!neabbs!richard)