Very Computer

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)

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

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