Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!iuvax!cica!tut.cis.ohio-state.edu!bloom-beacon!mcgill-vision!quiche!calvin!goof
From: goof@quiche.cs.mcgill.ca (Paul LOSORDO)
Newsgroups: comp.unix.wizards
Subject: Signals on Sys V
Summary: Light Weight Processes / Context Switch problem
Keywords: SCO Sys V, LPW, Signals
Message-ID: <1745@calvin.cs.mcgill.ca>
Date: 12 Nov 89 03:50:13 GMT
Reply-To: goof@calvin.cs.mcgill.ca (Paul LOSORDO)
Distribution: na
Organization: SOCS, McGill University, Montreal, Canada
Lines: 49


OK Wizards 'n' Gurus ( whatever the definition might be, refer to last
98 postings... ), time to show your stuff!

I am trying to develop a light-weight processes package for SCO Sys V,
V 3.2 and I am having troubles getting signals to behave themselves.

The basic idea is to get concurrent processes under a scheduler inside
a given task. The initial process ( main() ) sets up a signal handler 
for SIGALRM and keeps on chugging until the alarm comes up. At this
point, the handler calls the scheduler to know whose turn it is to run 
and then does a context switch to that next process.


That's the theory... Now the glitches...

The Kernel Signal Dispatcher conveniently leaves on the stack all the
context information I need. These 24 longs words are my registers, 
segment pointers ( I'm on a 386 ), return address, etc. This known 
information accounts for 19 of the 24 longs. At words 14 and 15, and
22 to 24 ( from top of stack ) are values unaccounted for, usually 
containing 0 ( but not always ). What I tried to do is to pass these 5
values to the new process and hope for the best... Almost works...

The first context switch works fine. The handler resets the alarm and
returns to the next process ( on its private stack, allocated from the
heap ). The problem is that the next alarm seems to be duplicated, ie.
the alarm comes in and before it has time to react seems to send a
second one. Since the Dispatcher sets the handler to SIGDFL, this has
the infortunate effect of killing my process. I traced all this with
ADB, and everything, including sigarray looks fine up to the alarm.
At this point, when I tell it to continue with signal 14, it dies 
with a 'Alarm clock - Process terminated' message. Yes, I did reset 
the signal call when I exited the scheduler. 


Now the questions :

	a) Is it possible at all? Am I questing the Graal?
	b) What are these 5 unknown values? They have to be important,
	   but there doesn't seem to be much in there.
	c) Where is that spurious alarm coming from? 

Anybody with signal handling experience and/or access to Sys V source
and/or just plain common sense care to comment? I am accepting facts,
information, hear-say, rumours, slurs, even flames ( I'm that despe-
rate!!! ) ... Any idea will be greatly appreciated.

Louis Ayotte ( on Paul's account ).