[OpenAFS-devel] 1.2.9: Pthreads and signals (cut at col 70

[Harald Barth]

> It looks like non-portability to
> DUX is just a lack of POSIX support

It is not POSIX-mumble-2001, it is some early POSIX-mumble-1995. I
don't know if the EINTR stuff was fixed before or after the paper went
from draft to standard. I think a similar issue was in Solaris around
2.5.

> Note that it's not necessary to block SIGUSR1 in threads other than the
> softsig_thread.  

True. But if SIGUSR1 is used by the softsig thread for other purposes,
it will be useless for signals from the outside anyway. Right?

> When a softsig signal is handled by some thread, it calls
> sogsift_handler()

But the softsig thread can not do this.

> which registes the event in softsig_sigs[] and then
> sends SIGUSR1 to softsig_thread directly: note the use of pthread_kill()
> as opposed to kill().

> One problem that I didn't expect is that sigwait() blocks SIGSEGV et al,
> so on Linux the softsig_thread doesn't die when the rest of the process
> crashes. 

I think SIGSEGV is not blocked by AFS_SIGSET_CLEAR(). So how could the
softsig thread still be lingering around? Is this a Linux bug?
see include/afs/pthread_nosigs.h

>  This is kind-of unfortunate.  Another problem is that, again on
> Linux, you can't send signals to the softsig_thread PID of the process,
> you have to use the PID of some other thread.

My second patch opens up the softsig_thread to handle signals which
were registered by softsig_signal. It does not take in account signals
which were not registered. If you want that, you can choose to not
block anything in the softsig thread and catch the EINTR instead. Then
you have to panic manually if the signal was not registered in the
array. However, I think this is more complicated as that might leave a
time window open in which you panic on a legitimate signal because
softsig_signal for that signal has not yet be called from another
thread.

Latest version of my patch can be found at
/afs/pdc.kth.se/home/h/haba/Public/openafs-pthread-signal*.patch
Choose the biggest number.

Harald.