Date: Mon, 20 Mar 2000 10:40:03 -0800 (PST) From: Don Lewis <Don.Lewis@tsc.tdk.com> To: freebsd-bugs@FreeBSD.org Subject: Re: kern/8324 Message-ID: <200003201840.KAA71109@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR kern/8324; it has been noted by GNATS. 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 ... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200003201840.KAA71109>