From nobody@FreeBSD.ORG  Wed Jun  7 01:38:25 2000
Return-Path: <nobody@FreeBSD.ORG>
Received: by hub.freebsd.org (Postfix, from userid 32767)
	id CCB5037B8B2; Wed,  7 Jun 2000 01:38:25 -0700 (PDT)
Message-Id: <20000607083825.CCB5037B8B2@hub.freebsd.org>
Date: Wed,  7 Jun 2000 01:38:25 -0700 (PDT)
From: bryanm@is.co.za
Sender: nobody@FreeBSD.ORG
To: freebsd-gnats-submit@FreeBSD.org
Subject: selects always restart when using threads
X-Send-Pr-Version: www-1.0

>Number:         19087
>Category:       misc
>Synopsis:       selects always restart when using threads
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    deischen
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Wed Jun 07 01:40:00 PDT 2000
>Closed-Date:    Fri Nov 17 15:56:59 PST 2000
>Last-Modified:  Fri Nov 17 16:00:17 PST 2000
>Originator:     Bryan Mawhinney
>Release:        4.0-RELEASE
>Organization:
The Internet Solution
>Environment:
FreeBSD some.host 4.0-RELEASE FreeBSD 4.0-RELEASE #2: Thu May 18 16:27:
16 SAST 2000      bryanm@is.co.za:/usr/src/sys/compile/VISP  i386
>Description:
Threads blocking on select default to being restarted after
signals.  Shouldn't the default be to interrupt, given that
these are POSIX threads?

Calling siginterrupt(1) doesn't help, since it isn't thread aware.
One has to use sigaction to explicity set sa_flags to 0 to get
the POSIX behaviour.

>How-To-Repeat:
In a threaded app (eg, slapd from openldap-1.2.10):

int shutdown = 0;
signal( SIGTERM, set_shutdown)

while (!shutdown) {
  i = select( nfds, &readfds, &writefds, 0, 0)
  ...
}

void set_shutdown( int sig )
{
  shutdown = 1
}

In response to a SIGTERM, shutdown is set to 1, but if the fds
are idle, the process never exits because the select restarts
each time.

>Fix:
libc_r includes an implementation of signal which implements
the POSIX semantics, but it is not listed in HIDDEN_SYSCALLS,
so the libc implementation gets used anyway.

Is this an oversight, or is this merely a porting issue?
Are there any other side effects due to calling the libc signal?


>Release-Note:
>Audit-Trail:
Responsible-Changed-From-To: freebsd-bugs->jasone 
Responsible-Changed-By: jasone 
Responsible-Changed-When: Wed Jun 7 12:36:07 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:53:07 PDT 2000 
State-Changed-Why:  
Take over responsiblity for this; I've got some threads library 
changes in the pipe. 

signal(3) installs signal handlers using sigaction(2) and sets the 
sa_flags to SA_RESTART.  Before sigaction(2), earlier BSDs automatically 
restarted some system calls when handlers were installed using signal(2). 
Now, the library routine signal(3) tries to keep this behaviour by 
using SA_RESTART, and the threads library obeys this flag.  signal(3) 
should be deprecated in preference to the POSIX sigaction().  Use 
sigaction() to install the signal handler with sa_flags set to 0, and 
select() will be interrupted upon receipt of a signal. 

I want to close this PR, but will wait a bit for response from the 
submitter. 


Responsible-Changed-From-To: jasone->deischen 
Responsible-Changed-By: deischen 
Responsible-Changed-When: Mon Sep 4 06:53:07 PDT 2000 
Responsible-Changed-Why:  
I've got changes to signal handling in the threads library in the 
works. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=19087 
State-Changed-From-To: analyzed->closed 
State-Changed-By: deischen 
State-Changed-When: Fri Nov 17 15:56:59 PST 2000 
State-Changed-Why:  
This has been fixed in both -current and -stable. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=19087 
>Unformatted:
