Conference clt::cma

Pat,

I'm afraid that the term "secondary signal handler" doesn't hold any more
meaning for us than it does for you.  

On the other hand, as far as I know, the phrase "Digital UNIX 4.1" doesn't mean
much either, at this point!  There is a release whose codename is "Steel" which
is the current "next major functional release following V4.0" and which is
likely to be given the number V4.1, but there is no much definite at this time. 
Steel hasn't even reached IFT functional code freeze yet.  So, it seems a little
weird that its features would be being discussed widely at this point.

.0> This call was handed to me by someone in the premium services team as a 
.0> critical call

A what?  Queries from customers about uncommitted functionality can constitute a
"critical call"?  Geez!  :-p


Anyway, between V3 and V4 there were some changes to signal handling.  For
instance, in V3, for a given "synchronous" signal (e.g., SIGSEGV), each thread
could have a different signal handler routine; however, for a given
"asynchronous" signal (e.g., SIGINT), all threads used the same signal handler
routine, and if any thread changed it, it was changed for all threads.  In V4,
there is no special treatment of handlers for synchronous signals; that is all
threads share each signal's handler regardless of whether the signal is
synchronous or asynchronous.

The other possibility for the customer's confusion would be that there were some
changes to the DECthreads exception handling package.  It now interoperates with
the native exceptions package.  And, in the case of an unhandled exception it
will only unwind the stack to the last "reraise" (if any), leaving a more useful
stack trace.

Other than these possibilities, I can't even guess what the customer thought he
heard about.  However, each of the above was put in place in V4.0 -- I'm not
aware of anything significant in "V4.1"...


				Webb

    
    Hmm... with "no special treatment" you refer to the handler only. Not
    to which thread a synchronous signal will be delivered to (the thread
    that generated it), just want to make sure.
    

I finally got in touch with the developer and now have
the real story.  All he wanted to know is how you can
control the handing of signals in a multithreaded 
program. I'm not sure where all this stuff about UNIX
4.1 came from.

Just to make sure I answered the question correctly...

His problem is that under 3.2-x all his signals are 
delivered to the "main" thread rather than the 
"secondary" threads created from the main program (thus
the term :secondary signal handler"). I explained the
differences between the way signals work on 3.2 vs 4.0,
and suggested using pthread_sigmask to enable/disable 
signals on a per thread basis. I then checked to see if
pthread_sigmask was present in 3.2 and didnt find it.
After a quick check in notes, it looks like he should 
use sigprocmask instead. Anything I missed?

Pat

Re .2:  In V4 a signal can be made to pend against either a specific thread or
against the process as a whole (in which case, the first eligible thread
receives it).  "Synchronous" signals (e.g., signals which result from faults or
traps) always pend against the thread which incurred the fault or trap.

In V4, if a thread establishes a signal handler for one of these signals, then
that signal handler will be executed in some other thread if that other thread
incurs the specific fault or trap.


					Webb

In addition to having its own mask of pending signals, each thread has its own
mask of blocked signals.  When a thread is created, it inherits the signal
(blocked) mask of its creator.  

Thus, the easiest (and most reliable) way to proceed is to block the signals in
the "main" thread (whichever one that is -- your perspective may vary depending
on whether you're an application developer or an API provider) and keep them
blocked while you create any subordinate threads.  Thus, each thread (including
the "main" thread) can unblock them later as needed (or call sigpause() or
sigwait() or whatever).  [You'll probably only actually want to block a subset
of signals:  you can't block SIGKILL or SIGSTOP, and you probably don't want to
block the synchronous signals like SIGSEGV, SIGBUS, SIGTRAP, etc; so, take some
care.]


				Webb

>His problem is that under 3.2-x all his signals are 
<delivered to the "main" thread rather than the 
>"secondary" threads created from the main program (thus
>the term :secondary signal handler"). I explained the
>differences between the way signals work on 3.2 vs 4.0,
>and suggested using pthread_sigmask to enable/disable 
>signals on a per thread basis. I then checked to see if
>pthread_sigmask was present in 3.2 and didnt find it.
>After a quick check in notes, it looks like he should 
>use sigprocmask instead. Anything I missed?

No, there's NOTHING that can be done about this on 3.2. Asynchronous signals
are delivered to the main thread, and that's it. (Note that "synchronous"
signals, like SIGSEGV, were always delivered to the thread that caused the
problem.) You can't use sigprocmask (or, if it existed, pthread_sigmask) to
change this, because the "problem" (it's really a "restriction") has nothing
to do with the signal mask.

On 4.0, the kernel knows how to deliver async signals to any thread with the
signal unmasked. However, if you create a thread using the DCE thread or CMA
interfaces on 4.0, the thread will be created with all "asynchronous" signals
masked -- this provides behavior somewhat compatible with the pre-4.0 model.
(And, believe it or not, some applications, and the DEC Ada runtime, depended
on the fact that async signals would occur only in the main thread.) When you
convert to the POSIX interface, threads are created with the signal mask of
the creating thread.

	/dave

    I should probably keep my mouth shut (always a good idea, I've
    been told repeatedly), but prior to V4.0, there's one little loophole
    in the "main thread gets asynch signals" rule. If you send an excpetion
    signal, e.g., SIGEGV, via an asynch mechansim (say, kill), it can
    go to an arbitrary thread that has it unmasked. You can in fact use
    this mechanism to create some v4.0-like behaviors. But it means
    threads will have to block signals SEGV, which is a pretty bad
    idea. SIGBUS and SIGPIPE are possibly a little safer, depending
    on the application.
    
    But this is really hacky, so forget I said anything....