Very Computer

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
>incremented.
>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
returns.

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 :-(

Anders

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
>returns.

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()
instead.

Casper
--
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)

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
undefined.

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.

Linus

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.

Regards,

/mtp

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

Very Computer

Q: Puzzling Linux/OSF signal semantics

Q: Puzzling Linux/OSF signal semantics

Q: Puzzling Linux/OSF signal semantics

Q: Puzzling Linux/OSF signal semantics

Q: Puzzling Linux/OSF signal semantics