From archie@whistle.com  Wed Oct 14 22:17:54 1998
Received: from whistle.com (s205m131.whistle.com [207.76.205.131])
          by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id WAA04567
          for <FreeBSD-gnats-submit@freebsd.org>; Wed, 14 Oct 1998 22:17:54 -0700 (PDT)
          (envelope-from archie@whistle.com)
Received: (from smap@localhost) by whistle.com (8.7.5/8.6.12) id WAA06764 for <FreeBSD-gnats-submit@freebsd.org>; Wed, 14 Oct 1998 22:17:38 -0700 (PDT)
Received: from bubba.whistle.com(207.76.205.7) by whistle.com via smap (V1.3)
	id sma006760; Wed Oct 14 22:17:35 1998
Received: (from archie@localhost) by bubba.whistle.com (8.8.7/8.6.12) id WAA11996; Wed, 14 Oct 1998 22:17:35 -0700 (PDT)
Message-Id: <199810150517.WAA11996@bubba.whistle.com>
Date: Wed, 14 Oct 1998 22:17:35 -0700 (PDT)
From: Archie Cobbs <archie@whistle.com>
Reply-To: archie@whistle.com
To: FreeBSD-gnats-submit@freebsd.org
Subject: failure to deliver SIGIO when fildes marked for async i/o
X-Send-Pr-Version: 3.2

>Number:         8324
>Category:       kern
>Synopsis:       failure to deliver SIGIO when fildes marked for async i/o
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    freebsd-bugs
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Wed Oct 14 22:20:00 PDT 1998
>Closed-Date:    Tue May 30 15:30:40 PDT 2000
>Last-Modified:  Tue May 30 15:31:17 PDT 2000
>Originator:     Archie Cobbs
>Release:        FreeBSD 2.2.6-RELEASE i386
>Organization:
Whistle Communications, Inc.
>Environment:

	2.2.7 and 3.0

>Description:

	Run the program below. It will periodically hang until
	you press return (which causes a readability condition).
	It should (as far as I can tell) generate continuous
	output without pausing at all.

>How-To-Repeat:


> From majordom@FreeBSD.ORG Wed Oct 14 18:42:26 1998
> From: Archie Cobbs <archie@whistle.com>
> Message-Id: <199810150118.SAA02921@bubba.whistle.com>
> Subject: bug with SIGIO?
> To: freebsd-hackers@FreeBSD.ORG
> Date: Wed, 14 Oct 1998 18:18:55 -0700 (PDT)
> X-Mailer: ELM [version 2.4ME+ PL38 (25)]
> MIME-Version: 1.0
> Content-Type: text/plain; charset=US-ASCII
> Content-Transfer-Encoding: 7bit
> Sender: owner-freebsd-hackers@FreeBSD.ORG
> Precedence: bulk
> X-Loop: FreeBSD.ORG
> Status: RO
> 
> Hi,
> The program included below seems to indicate a bug with SIGIO,
> in that the process is not always getting signalled when the
> file descriptor is writable.
> 
> If you run this program, it outputs for a while, then stops,
> then resumes when you hit return (which causes a readable condition).
> 
> I've verified this behavior in 2.2.7 but not 3.0-current.
> 
> Q1. Is this in fact a bug, or else a misunderstanding?
> Q2. If this is not a bug, what is the correct way to do this?
> 
> I apologize if this is already know; didn't find anything
> in the PR database.
> 
> Thanks,
> -Archie
> 
> ___________________________________________________________________________
> Archie Cobbs   *   Whistle Communications, Inc.  *   http://www.whistle.com
> 
> #include <fcntl.h>
> #include <stdio.h>
> #include <signal.h>
> #include <unistd.h>
> #include <errno.h>
> #include <sys/ioctl.h>
> 
> void catch() { }
> 
> int
> main(int ac, void *av[])
> {
> 	sigset_t empty, block;
> 	int on = 1;
> 
> 	fcntl(1, F_SETFL, O_NONBLOCK);
> 	ioctl(1, FIOASYNC, &on);
> 
> 	sigemptyset(&empty);
> 	sigemptyset(&block);
> 	sigaddset(&block, SIGIO);
> 	sigprocmask(SIG_BLOCK, &block, NULL);
> 	signal(SIGIO, catch);
> 
> 	for (;;) {
> 		int w = write(1, "!@#$%", 5);
> 		if (w < 0 && errno == EWOULDBLOCK) {
> 			sigsuspend(&empty);
> 			write(1, " resumed ", 7);
> 		}
> 	}
> }
> 

>Fix:

	??

>Release-Note:
>Audit-Trail:

From: Bruce Evans <bde@zeta.org.au>
To: archie@whistle.com
Cc:  Subject: Re: kern/8324: failure to deliver SIGIO when fildes marked for async i/o
Date: Thu, 15 Oct 1998 17:52:43 +1000

 >>Description:
 >
 >	Run the program below. It will periodically hang until
 >	you press return (which causes a readability condition).
 >	It should (as far as I can tell) generate continuous
 >	output without pausing at all.
 
 The program seems to only make sense for ttys (fcntl returns a value
 which is always ignored...) and seems to only hang for ptys.  It hangs
 because wakeups for output-wouldn't block are only sent to processes
 in the kernel - for output there are only select-style wakeups, not
 SIGIO wakeups.  The select-style wakeups are poorly implemented too -
 processes gets woken up whenever the space in the output buffer increases,
 and then usually go back to sleep until the space reaches a watermark.
 
 While debugging this, I was reminded of other problems: the O_NONBLOCK
 and O_ASYNC flags are sticky, and syscons is not reentrant - a breakpoint
 in ttwakeup() soon caused a panic.
 
 Bruce
 

From: Alfred Perlstein <bright@wintelcom.net>
To: Archie Cobbs <archie@whistle.com>
Cc: freebsd-current@freebsd.org
Subject: Re: kern/8324
Date: Fri, 17 Mar 2000 18:27:56 -0800

 * Archie Cobbs <archie@whistle.com> [000317 17:55] wrote:
 > This bug has been around since at least 2.2.6 and is still present
 > in RELENG_3, RELENG_4, and -current.
 > 
 >   http://www.freebsd.org/cgi/query-pr.cgi?pr=8324
 > 
 > Is anyone planning to tackle it? What would be required to fix it?
 > (it's not clear (to me anyway) from Bruce's description how hard
 > this is to fix..)
 
 I think Bruce sort of went off into a tangent with his diagnosis,
 anyhow this is untested (of course :) ), but looks like the right
 thing to do (from sys_pipe.c).
 
 Perhaps the fcntls and ioctls aren't being propogated enough to set
 the flags properly, but if they are then it should work sort of the
 way SIGIO does, basically generating a signal for /some condition/
 on a descriptor.
 
 -- 
 -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org]
 
 Index: tty_pty.c
 ===================================================================
 RCS file: /home/ncvs/src/sys/kern/tty_pty.c,v
 retrieving revision 1.74
 diff -u -u -r1.74 tty_pty.c
 --- tty_pty.c	2000/02/09 03:32:11	1.74
 +++ tty_pty.c	2000/03/18 06:12:55
 @@ -337,6 +337,8 @@
  		selwakeup(&pti->pt_selw);
  		wakeup(TSA_PTC_WRITE(tp));
  	}
 +	if ((tp->t_state & TS_ASYNC) && tp->t_sigio)
 +		pgsigio(tp->t_sigio, SIGIO, 0);
  }
  
  static	int
 
 
 
 

From: Don Lewis <Don.Lewis@tsc.tdk.com>
To: Alfred Perlstein <bright@wintelcom.net>,
	Archie Cobbs <archie@whistle.com>
Cc: freebsd-current@freebsd.org
Subject: Re: kern/8324
Date: Sat, 18 Mar 2000 03:52:54 -0800

 On Mar 17,  6:27pm, Alfred Perlstein wrote:
 } Subject: Re: kern/8324
 } * Archie Cobbs <archie@whistle.com> [000317 17:55] wrote:
 } > This bug has been around since at least 2.2.6 and is still present
 } > in RELENG_3, RELENG_4, and -current.
 } > 
 } >   http://www.freebsd.org/cgi/query-pr.cgi?pr=8324
 } > 
 } > Is anyone planning to tackle it? What would be required to fix it?
 } > (it's not clear (to me anyway) from Bruce's description how hard
 } > this is to fix..)
 
 I never heard of using SIGIO for output, but section 6.4 of the daemon
 book says that SIGIO is sent "when a read or write becomes possible".
 On the other hand, section 10.8 (Terminal Operations) mentions SIGIO 
 for input but not for output.  I also looked at rev 1.1 of kern/tty.c
 and it only sends a SIGIO when input is ready, so this seems to be
 the historical behaviour, so I'm suprised that this program even
 worked with plain tty devices.
 
 } I think Bruce sort of went off into a tangent with his diagnosis,
 } anyhow this is untested (of course :) ), but looks like the right
 } thing to do (from sys_pipe.c).
 } 
 } Perhaps the fcntls and ioctls aren't being propogated enough to set
 } the flags properly, but if they are then it should work sort of the
 } way SIGIO does, basically generating a signal for /some condition/
 } on a descriptor.
 
 This patch (vs the 3.4-STABLE version of tty.c) causes SIGIO to be
 sent when a regular or pseudo tty becomes writeable.
 
 
 --- tty.c.orig	Sun Aug 29 09:26:09 1999
 +++ tty.c	Sat Mar 18 03:09:32 2000
 @@ -2133,6 +2133,8 @@
  
  	if (tp->t_wsel.si_pid != 0 && tp->t_outq.c_cc <= tp->t_olowat)
  		selwakeup(&tp->t_wsel);
 +	if (ISSET(tp->t_state, TS_ASYNC) && tp->t_sigio != NULL)
 +		pgsigio(tp->t_sigio, SIGIO, (tp->t_session != NULL));
  	if (ISSET(tp->t_state, TS_BUSY | TS_SO_OCOMPLETE) ==
  	    TS_SO_OCOMPLETE && tp->t_outq.c_cc == 0) {
  		CLR(tp->t_state, TS_SO_OCOMPLETE);
 
 
 BTW, I had to add:
 	fcntl(1, F_SETOWN, getpid());
 to the test program since there is no longer a default target to send
 the signal to.  The old scheme had the defect of sending SIGIO to the
 process group that owned the terminal, which implied that the terminal
 had to be the controlling terminal for the process group.  This limited
 a process to only receiving SIGIO from one terminal device even if it
 had more than one open and it wanted to receive SIGIO from all of them.
 Also, SIGIO was sent to the entire process group, but it may be desireable
 to limit this to one process.  I wonder if it might make sense to go
 back to the old default for tty devices so that processes only receive
 SIGIO when they are in the foreground ...
 
 
State-Changed-From-To: open->closed 
State-Changed-By: archie 
State-Changed-When: Tue May 30 15:30:40 PDT 2000 
State-Changed-Why:  
Fixed in revision 1.130 of sys/kern/tty.c. MFC'd to 4.0-stable and 3.0-stable. 

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