SYS V sigset(2)

[Jeff Bowles]

In article <507 at micropen> dave at 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