goof@quiche.cs.mcgill.ca (Paul LOSORDO) (11/12/89)
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 ).
larry@hcr.uucp (Larry Philps) (11/13/89)
In article <1745@calvin.cs.mcgill.ca> goof@calvin.cs.mcgill.ca (Paul LOSORDO) writes: > ... >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. > ... >second one. Since the Dispatcher sets the handler to SIGDFL, this has >the infortunate effect of killing my process. In System V Release 3 there are two signal interfaces. The one you get with the "signal" system call is the old (but still there for compatability) broken one in which most signals are reset to SIGDFL when taken. The other interface appeared in R3 and is accessed via the "sigset" system call (same arguments as "signal"). Signal handlers invoked after a sigset behave just like Berkeley signals, that is ensuing signals of the same type are blocked while the signal handler is running. Just put a #define signal sigset at the start of your program and see if that fixes the problems. Your program will certainly be more reliable. Larry Philps HCR Corporation 130 Bloor St. West, 10th floor Toronto, Ontario. M5S 1N5 (416) 922-1937 {utzoo,utcsri}!hcr!larry
dougm@queso.ico.isc.com (Doug McCallum) (11/15/89)
In article <1989Nov13.140120.17775@hcr.uucp> larry@hcr.uucp (Larry Philps) writes:
...
The other interface appeared in R3 and is accessed via the "sigset" system
call (same arguments as "signal"). Signal handlers invoked after a sigset
behave just like Berkeley signals, that is ensuing signals of the same type
are blocked while the signal handler is running. Just put a
Almost the same as Berkeley signals but there are some subtle
differences.
#define signal sigset
at the start of your program and see if that fixes the problems. Your
program will certainly be more reliable.
While the above will work for nearly all cases, it can fail. One of
the differences that can catch the unwary, especially when porting BSD
software, is that a "longjmp" out of a signal handler will reset the
signal to the non-hold state on a BSD system while on a V.3 system you
have to explicitly release the hold. This could be important in the
case where the stack is being manipulated and the signal handler isn't
returned from directly.
Its also too bad that the "sighold()" and "sigrelse()" calls only take
a signal number and not a mask as with the BSD equivalents.sms@WLV.IMSD.CONTEL.COM (Steven M. Schultz) (11/15/89)
In article <DOUGM.89Nov14135134@queso.ico.isc.com> dougm@queso.ico.isc.com (Doug McCallum) writes: > >Its also too bad that the "sighold()" and "sigrelse()" calls only take >a signal number and not a mask as with the BSD equivalents. It does seem strange that the 2.8/2.9BSD libjobs functionality from 1983/4 was implemented rather than the 4.2/3BSD signal semantics. So System V has finally caught up with 2.9BSD, congrats ;-) Steven M. Schultz sms@wlv.imsd.contel.com
gwyn@smoke.BRL.MIL (Doug Gwyn) (11/16/89)
In article <40629@wlbr.IMSD.CONTEL.COM> sms@WLV.IMSD.CONTEL.COM.UUCP (Steven M. Schultz) writes: >In article <DOUGM.89Nov14135134@queso.ico.isc.com> dougm@queso.ico.isc.com (Doug McCallum) writes: >>Its also too bad that the "sighold()" and "sigrelse()" calls only take >>a signal number and not a mask as with the BSD equivalents. > It does seem strange that the 2.8/2.9BSD libjobs functionality > from 1983/4 was implemented rather than the 4.2/3BSD signal > semantics. So System V has finally caught up with 2.9BSD, > congrats ;-) That's a rather pointless posting. If you check out the time frame for the SVR3 implementation, it would come as no surprise that the 4.1BSD semantics were used as the base model. Meanwhile, SVR4.0 has come out with full POSIX (IEEE 1003.1) semantics, which goes beyond 4.3BSD. I won't go into the history of the POSIX spec and why it differed from 4.2BSD, but there would valid reasons (I was there).
guy@auspex.auspex.com (Guy Harris) (11/21/89)
> It does seem strange that the 2.8/2.9BSD libjobs functionality > from 1983/4 was implemented rather than the 4.2/3BSD signal > semantics. So System V has finally caught up with 2.9BSD, > congrats ;-) System V Release 4 offers the POSIX signal mechanism, so it's finally caught up with (and passed) 4.3BSD (4.4BSD will presumably catch up there).