From nobody@FreeBSD.ORG  Mon May 15 01:56:29 2000
Return-Path: <nobody@FreeBSD.ORG>
Received: by hub.freebsd.org (Postfix, from userid 32767)
	id 8023E37B52A; Mon, 15 May 2000 01:56:29 -0700 (PDT)
Message-Id: <20000515085629.8023E37B52A@hub.freebsd.org>
Date: Mon, 15 May 2000 01:56:29 -0700 (PDT)
From: hwc@openfind.com.tw
Sender: nobody@FreeBSD.ORG
To: freebsd-gnats-submit@FreeBSD.org
Subject: pthread_self and signal handler (SIGPIPE)
X-Send-Pr-Version: www-1.0

>Number:         18559
>Category:       misc
>Synopsis:       pthread_self and signal handler (SIGPIPE)
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    jasone
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          wish
>Submitter-Id:   current-users
>Arrival-Date:   Mon May 15 02:00:01 PDT 2000
>Closed-Date:    Mon Nov 6 18:34:46 PST 2000
>Last-Modified:  Mon Nov  6 18:36:00 PST 2000
>Originator:     Huang Wei-Chen
>Release:        FreeBSD 4.0
>Organization:
openfind (http://www.openfind.com)
>Environment:
FreeBSD sable1.iis.sinica.edu.tw 4.0-STABLE FreeBSD 4.0-STABLE #1: Fri May 12 11:19:20 CST 2000     root@sable1.iis.
sinica.edu.tw:/usr/src/sys/compile/SABLE1_MP  i386



>Description:
I don't knwow is this a bug....


In the thread before use
   send(...)
I'v use
   signal(SIGPIPE,sig_handler);
In sig_handler,
   fprintf(g_log,"%d\t",pthread_self())

but I found, in sig_handler,
   the thread_self return main's thread_id,
   not the thread that use "send" ...


I'v use this code in linux,
in sig_handler,
   the thread_self return "send" thread id, as I'm assumed..

Is freebsd normal ?
I'v traced 
	/usr/src/lib/libc_r/uthread_sig.c
-rw-r--r--  1 root  wheel  20777   3/22 09:19 uthread_sig.c
when SIGPIPE occurs, in 
   _thread_sig_handler(int sig, int code, ucontext_t * scp)
the 
   _thread_run (global variable, pthread_self?)
is the the "send" thread,
but the
   _thread_sig_handle(sig, scp);
return the main thread

I'v modified some code in _thread_sig_handle,
	/usr/src/lib/libc_r/uthread_sig.c, line 323
	
                if ((_thread_sigact[sig - 1].sa_handler == SIG_IGN) ||
                    (_thread_sigact[sig - 1].sa_handler == SIG_DFL))
                        handler_installed = 0;
                else
                        handler_installed = 1;
/**** my code added begin***/
                if (sig==SIGPIPE && handler_installed==1  &&   !sigismember(&_thread_run->sigmask, sig))
                         signaled_thread = _thread_run;
                else
/**** my code end***/
                for (pthread = TAILQ_FIRST(&_waitingq);
                    pthread != NULL; pthread = pthread_next) {
                        /*
                         * Grab the next thread before possibly destroying
                         * the link entry.
                         */
                        pthread_next = TAILQ_NEXT(pthread, pqe);

                               if (sig==SIGPIPE && handler_installed==1)
                                {
                                    if (!sigismember(&_thread_run->sigmask, sig)) {
                                                signaled_thread = _thread_run;

Seems fine......
I don't know will it produce side effect?




>How-To-Repeat:

>Fix:


>Release-Note:
>Audit-Trail:
Responsible-Changed-From-To: freebsd-bugs->jasone 
Responsible-Changed-By: jasone 
Responsible-Changed-When: Mon May 15 12:58:34 PDT 2000 
Responsible-Changed-Why:  
Over to maintainer. 
State-Changed-From-To: open->analyzed 
State-Changed-By: deischen 
State-Changed-When: Mon Sep 4 06:39:29 PDT 2000 
State-Changed-Why:  
The problem seems to be that the main thread doesn't have SIGPIPE 
masked.  In a threaded program, to ensure signals are delivered to 
the desired thread, you should set the signal mask accordingly. 
POSIX states that threads are selected for signal delivery in the 
following order: 

o Threads in sigwait with the signal in the wait mask 
(signal handler not installed) 
o Threads in sigsuspend with the signal being unblocked 
in the threads mask 

In lieu of finding a thread for one of the above, it is unspecified 
which thread should be selected for signal delivery.  Our threads 
library chooses the first thread it finds with the signal unmasked. 
A properly written program should explicitly set the signal mask 
for threads that want to handle signals.  Please try doing that 
and report back if things are not working as expected. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=18559 
State-Changed-From-To: analyzed->closed 
State-Changed-By: jasone 
State-Changed-When: Mon Nov 6 18:34:46 PST 2000 
State-Changed-Why:  
No additional feedback after analysis (5 1/2 months ago). 
>Unformatted:
