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

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

Post by Don Waugam » Sun, 20 Feb 1994 05:49:21



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.

Questions:

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
        signals?

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

                        - Don (not speaking for UA)

 
 
 

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

Post by Zeyd M. Ben-Hal » Mon, 21 Feb 1994 09:50:47




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

There are several different semantics between BSD signal() and
SYSV signal() which is what Linux seems to use.
Under Linux after the signal handler is done, it is not re-established.
So the next time the signal occurs it will be handled with the default
handler. BSD semantics WILL re-establish the signal handler. To get
this aspect of behavior use -D__USE_BSD_SIGNAL.

Quote:>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.

This introduces more problems which should be handled with sigaction()
since signal() is implemted in terms of it.

Quote:>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.

You can try unblocking the signal before you do longjmp(). SVR4
has a SA_NODEFER option to disable blocking but this is unsupported
by Linux. Be forwarned that signals may occur between you unblocking
the signal and the call to longjpm().

Your exact problem is described in "Advanced Programming in the
UNIX Enviroment" in section 10.15. The solution offered by POSIX
is to use sigsetjmp() and siglongjmp().

Quote:>Questions:

>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
>    signals?

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

>                    - Don (not speaking for UA)

--
---

10479 1/4 Santa Monica Blvd, LA, CA, 90025 (310) 470-0281

 
 
 

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

Post by Bruce Eva » Tue, 22 Feb 1994 17:47:55




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

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

The Linux signal() uses the SA_NOMASK sigaction flag to give
(unreliable) SYSV signal semantics.  You don't want unreliable
signals, but longjmp() ought to work with them.  It's better to
use sigaction together with siglongjmp().

Quote:>I have tried:

>1)  Compiling with -I/usr/include/bsd & -D__FAVOR_BSD

This ought to work.  It is supposed to turn setjmp/longjmp() into
sigsetjmp/siglongjmp(), so signals should be unblocked like you want for
new threads, and using linux signal() shouldn't hurt because the use of
SA_NOMASK means that the signal mask is almost always 0 so restoring it
makes no difference.

BSD signal semantics are supposed to be obtainable by defining
__USE_BSD_SIGNAL, but they aren't unless __FAVOR_BSD somehow gets
defined too (you get a broken longjmp() without it).  All modules,
including libraries, must be compiled with consistent flags.

Quote:>a)  Is there another flag in sa_flags to set to emulate Dynix'
>    (BSD-ish) signals?  Or compile flags or libraries to try?

Only the SA_RESTART flag and someday the SA_STACK flags.  SA_NOMASK
and SA_ONESHOT are to provide unreliable signals and SA_INTERRUPT
is a no-op.

Quote:>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.

The POSIX standard.
--

 
 
 

1. telnet -E and BSD signal semantics

I have an application for which I need to execute telnet -E (which on
linux systems eliminates the functioning of the escape character).
Unfortunately, AIX telnet does not support this option.

So, I thought I would download some telnet souce code and comment out
the appropriate line(s) or just compile a version support the -E option.

Well, I cannot seem to find unix telnet source. However, I finally just
pulled the source from linux packages (which compiles on every version
of unix BUT AIX). When attempting to run ./configure on AIX, I get an
error about BSD Signal Semantics not being found.

So, I either need telnet source code for AIX, a version of telnet (C,
C++, perl, etc) that will allow me to disable the escape character, or a
way to get around that BSD Signal Semantics error.

Thanks for all your help!

-Dave Botsch

2. where can one find "eqn"?

3. Q: Puzzling Linux/OSF signal semantics

4. finding out the system's CPU

5. SBC with Power fail signal impending signal, to allow Linux to shutdown properly

6. Multi-home issue (network address as default gateway?)

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

8. ne2000 card can't ping

9. signal semantics are a pain in the arse

10. BSD Signals on Linux

11. BSD signals on Linux: HELP!

12. Signal handler for unaligned access: emulate and continue?