Q: Puzzling Linux/OSF signal semantics

Q: Puzzling Linux/OSF signal semantics

Post by Anders Gustafss » Thu, 08 Jun 1995 04:00:00

>The following program executes differently on Digital's UNIX and Public
>Domain Linux (V1.1.59).  The intention of the program is to test whether
>an O/S blocks delivery of SIGVTALRM before the signal handler from a previous
>SIGVTALRM can complete.
>The test is really simple.  The signal handler, timer_func(), just executes a
>tight loop for a period longer than that set by setitimer and maintains a
>count of the number of times timer_func() is reentered.  Thus, if the OS
>delivers a SIGVTALRM while timer_func() is in progress, its reentry_count
>On Digital's UNIX V3.2 (nee OSF/1), timer_func() is reentered, just as you
>would expect if the OS delivers all signals no matter what signal may be
>in progress.  On Linux V1.1.59, just the opposite occurs.  Running on a
>Pentium 90, no matter how long I arrange for timer_func() to execute, a
>second SIGVTALRM is *never* delivered.

I believe that the Linux system is correct, the Dec system not. I do not
have the POSIX standard before me, but I have read the relevant sections.
When a signal is delivered, and the handler executed, the signal being
delivered should be automatically blocked until the signal handler

I encountered the same problem on a version (don't remember which) of
Interactive Unix, with the SIGUSR1 signal, when we were porting a
product to that environment. I notified the supplier, and they sent me
a newer version of the OS, where the problem was fixed. But this
worries me, since we are just planning to port the same product
to DecUnix :-(



Q: Puzzling Linux/OSF signal semantics

Post by Casper H.S. D » Sat, 10 Jun 1995 04:00:00

>I believe that the Linux system is correct, the Dec system not. I do not
>have the POSIX standard before me, but I have read the relevant sections.
>When a signal is delivered, and the handler executed, the signal being
>delivered should be automatically blocked until the signal handler

You're wrong.  signal() is not port of any POSIX standard that I'm
aware of.  It's only part of the C standard.  The two behaviours seen
are both "correct".  The traditional unix semantics are: don't block
and reset signal handler.  When BSD introduced reliable signals, some
idiot decided that it was just to hard to give this new and totally
different signal() call a new name.  There has been no end to the
misery caused by this decision to this day.

Avoid signal() in programs that target POSIX systems, use sigaction()

Casper Dik - Network Security Engineer - Sun Microsystems
This article is posted from my guest account at the University

Opinions expressed here are mine (but you're welcome to share them with me)


Q: Puzzling Linux/OSF signal semantics

Post by Linus Torval » Sun, 11 Jun 1995 04:00:00

>You might note that the original program _did_ use sigaction() instead of
>signal(), and it _did_ show differing behavior between DEC and Linux.

>Therefore, either such behavior is unspecified (which I don't think it is)
>or at least one of the systems has a bug.

You'll also notice that the original program used the "sa_flags" field
to the sigaction() system call, with other flags than SA_NOCLDSTOP.  As
SA_NOCLDSTOP is the only standard flag there is, the behaviour is indeed

Under linux, to get the behaviour he seemed to want, you need to use the
SA_NOMASK sa_flag value.  I don't know what the SVR4 name for this is,
but they have something that does the same thing.

I'd suggest against using these flags at all (apart from SA_NOCLDSTOP),
as it's non-portable.



Q: Puzzling Linux/OSF signal semantics

Post by Mike Peterso » Tue, 13 Jun 1995 04:00:00

I posted the question originally and have since learned that the kernel can be
instructed to deliver a specified signal before the previously delivered signal
handler has completed.  I was able to do this by [re]initializing the process's
signal mask upon entry into the signal handler.

I've also learned that sigaction always adds the current signal to the struct
sigaction's sa_mask field.  Since the sa_mask specifies additional signals to
be blocked while the signal handler is in progress, signal handlers can never
be reentered unless methods like that described above are used.



#      +--------------------------------------------------------------+
#      | Michael T. Peterson          | Digital Equip. Corp.          |
#      +--------------------------------------------------------------+


1. Linux signal() semantics - can BSD signal() be emulated?

I'm porting a piece of software from our school's Sequent Dynix
(a BSD-style OS) to Linux.  This software relies fairly heavily
on signals, but apparently the semantics of signals differs
between Dynix and Linux.

The problem is that the software uses signals to implement a
threads-style abstraction with preemption, i.e. setitimer() is
used to set up a SIGVTALRM every so often, then a longjmp() is
done to move to a different thread.  Under Dynix, the new thread
will be preempted and the signal handler called when the SIGVTALRM
is generated again by the timer.

Linux, however, is a different story.  Under Linux, the signal
is blocked until the signal handler returns, and thus the thread
that "takes over" will run until completion or until it
voluntarily yields (i.e. longjmp()s back to the thread that was
running in the signal handler, which returns from the handler).

I have tried:

1)      Compiling with -I/usr/include/bsd & -D__FAVOR_BSD
2)      Linking with -lbsd
3)      Turning off the SA_ONESHOT flag in the sa_flags structure
        using sigaction().
4)      Most combinations of (1)-(3) above.


a)      Is there another flag in sa_flags to set to emulate Dynix'
        (BSD-ish) signals?  Or compile flags or libraries to try?
b)      Is there any information about how signal handling and
        delivery in Linux work?  I poked around in the kernel for
        a while, but didn't make much headway.
c)      Do you have any other suggestions for BSD-like nonblocking

Many thanks.  I'll summarize any answers I get (via posting or
email) to the net.

                        - Don (not speaking for UA)

2. ghostview : adobe fonts ?

3. telnet -E and BSD signal semantics

4. Linux compatibility ?

5. Use "sigset" for correct "signal" semantics

6. stepping through a argument in ksh ?

7. signal semantics are a pain in the arse

8. Troubles with solaris 2.5.1 apache1.3.3 mysql 3.22.14

9. Signals and threads - still puzzling

10. Pipes and signals with X puzzle

11. signal puzzle

12. Pipes and signals with X puzzle

13. Learn OSF Technology at the OSF/DCE Conference