Date: Sat, 27 Sep 1997 10:29:14 +0200 From: j@uriah.heep.sax.de (J Wunsch) To: freebsd-hackers@FreeBSD.ORG Subject: Re: ee taking up weird cpu amount. Message-ID: <19970927102914.WI52706@uriah.heep.sax.de> In-Reply-To: <199709250742.AAA10411@usr03.primenet.com>; from Terry Lambert on Sep 25, 1997 07:41:59 %2B0000 References: <Pine.BSF.3.91.970925162705.262G-100000@panda.hilink.com.au> <199709250742.AAA10411@usr03.primenet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
As Terry Lambert wrote: > IMO, this is a bug in HUP processing. I think that HUP should be sent to > the process group members from the process group leaders before the tty > is revoked, instead of simply erroring out the reads/writes. > > SVR4, SVR3, SCO Xenix, SCO UNIX, UnixWare, Solaris, SunOS, Fortune, > Cubix, Huerikon, Arrete, Unisys UNIX, UNICOS, Linux, Cubix, Intel > UNIX, Intel Xenix, PrimeOS, ISC UNIX, Ultrix, OSF/1, OSF/2, Microport > UNIX v2, Microport UNIX v3, Altos Xenix and UNIX, Cogent, Coherent, > and practically every other UNIX on the planet does this. > > But FreeBSD does not. I've seen this problem on Illtrix on an old Vax2000 as well. To what shell are your claims above related? ksh has a weird (mis-)feature to lead all its kids to death when it dies itself. You have to explicitly make it forget about some child in order to prevent it from doing so, even if the child was in a background process group (albeit i usually prefer `kill -9 $$' to logout instead of dealing with this cr*p, or rather, i quickly `exec csh' before starting to work). csh never did it this way, it always left running background jobs alone, which sounds logical to me (why did you put it into a running state in background at all, if not for keeping it running?). So, take out the SVR3's above (for not having job control at all), use csh, and retry your tests. (You probably need to take out SCO as well, since what they call a csh is anything else but a csh.) Alternatively, use ksh93 on FreeBSD, and you'll see the same behaviour, i'm convinced. Btw., nvi doesn't suffer from this behaviour. Ignoring an error return from the input device is always an error on the side of the program in question. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19970927102914.WI52706>