Date: Sat, 27 Sep 1997 11:54:02 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: joerg_wunsch@uriah.heep.sax.de Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: ee taking up weird cpu amount. Message-ID: <199709271154.EAA24656@usr04.primenet.com> In-Reply-To: <19970927102914.WI52706@uriah.heep.sax.de> from "J Wunsch" at Sep 27, 97 10:29:14 am
next in thread | previous in thread | raw e-mail | index | archive | help
> > 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? None of them, of course. This has only to do with ourder of revoke() processing when revoke() is a result of on-to-off-DCD transition. > ksh has a weird (mis-)feature to lead all its kids to death when it > dies itself. This, of course, has to do with ksh's method of backgrounding a process. A process which is in the background is a chikd of init, and not a child of a process whose tty is being revoked -- and therefore can not be affected, one way or the other, by a revoke -- now can it? > 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?). The issue is legacy code for management of CPU time charges, IMO. The Bourne shell specifically distinguished children this way via the "nohup" mechansim. The csh implies "nohup" for all subshells, and in fact has a hard time implying non-"nohup" for a subshell. > 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. SVR3 supported "nohup". > 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. An error return is impossible in the normal signal propagation case, since a SIGHUP propagation will have occurred, and the shell will have exited, prior to the error case being present. Dealing with the error case is only a requirement of FreeBSD and several other "broken" systems. The only other one that springs to mind at present is the tty code for Heurikon systems (a fairly wierd off-brand system in any case). I have programmed serial I/O on over 140 UNIX implementations in my career, and only Heurikon and FreeBSD don't propagate SIGHUP as I would expect them to. Take that for what it's worth; if we are talking compatability with historical behaviour, it should be worth a lot. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199709271154.EAA24656>