dave@micropen (David F. Carlson) (06/15/88)
I have a program in which it is "useful" to have reliable signals,
and therefore I must use sigset(2) (under System Vr3.0).
Problem is that the man pages tell me that when I am in a handler the
signal is automatically set to SIG_HOLD. SIG_HOLD queues up to 1 occurance
if the signal is again received. However, I am finding by way of a stack
dump that my signal handler is being entered *again and again* even though
sigset(2) is being used throughout my entire process (for that signal and all
others.) Of course, the exclusive resource assumed by the signal handler is
locked by a previous entry and deadlock results. Why is the documented sighold
not stopping further occurances when I am in the signal handler?
Also, a related question:
How does sigpause(2) differ from pause(2) for waiting? The man pages
detail dire consequences for mixing signal(2) and sigset(2) but I see
little relation between pause(2) and sigset(2). Is there a hidden hazard
or is this only a problem of wating within a signal handler itself?
Any help would be appreciated. Funny how out of date things like Bach's
book are when it is barely 2 years old.
--
David F. Carlson, Micropen, Inc.
...!{ames|harvard|rutgers|topaz|...}!rochester!ur-valhalla!micropen!dave
"The faster I go, the behinder I get." --Lewis Carrollbowles@lll-crg.llnl.gov (Jeff Bowles) (06/15/88)
In article <507@micropen> dave@micropen (David F. Carlson) writes: > >I have a program in which it is "useful" to have reliable signals, >and therefore I must use sigset(2) (under System Vr3.0). > Now, before going any further, repeat after me: "System V Release N+1 must not change functionality of programs compiled to run under System V Release N." The reason that there are new system calls to support things you'd expect are two-line mods to existing system calls (like sigpause(2) springing up) boil down to the above compatibility goal. We can argue about whether SVR3 is incompatible with previous releases, but this is why. >Problem is that the man pages tell me that when I am in a handler the >signal is automatically set to SIG_HOLD. (Goes on to describe a troubled >stack in a dying program.) >Of course, the exclusive resource assumed by the signal handler is >locked by a previous entry and deadlock results. (Red light goes on.) If you need to exclusively lock something, why not use the file-record locking calls or semaphores? > How does sigpause(2) differ from pause(2) for waiting? The man pages > detail dire consequences for mixing signal(2) and sigset(2) but I see > little relation between pause(2) and sigset(2). Is there a hidden hazard > or is this only a problem of wating within a signal handler itself? Remember that pause(2) doesn't check for held signals - you could sleep on a signal that's currently held.... Jeff
rbj@cmr.icst.nbs.gov (Root Boy Jim) (06/24/88)
? From: Jeff Bowles <bowles@lll-crg.llnl.gov> ? Now, before going any further, repeat after me: "System V Release N+1 ? must not change functionality of programs compiled to run under System V ? Release N." So it would appear. Howver, if SV is truly to be merged with BSD, something must give, and there are definitely cases where the BSD approach is superior, or where TPC has added features of little value. One obvious impact is the file system reorganization that Sun and Berkeley are working on. Do any of the Sun people have anything to say about either of these two points? ? Jeff (Root Boy) Jim Cottrell <rbj@icst-cmr.arpa> National Bureau of Standards Flamer's Hotline: (301) 975-5688 The opinions expressed are solely my own and do not reflect NBS policy or agreement Careful with that VAX Eugene!