Date: Sat, 27 Sep 1997 14:50:07 +0200 From: j@uriah.heep.sax.de (J Wunsch) To: freebsd-hackers@FreeBSD.ORG Subject: Re: ee taking up weird cpu amount. Message-ID: <19970927145007.HB02894@uriah.heep.sax.de> In-Reply-To: <199709271154.EAA24656@usr04.primenet.com>; from Terry Lambert on Sep 27, 1997 11:54:02 %2B0000 References: <19970927102914.WI52706@uriah.heep.sax.de> <199709271154.EAA24656@usr04.primenet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
As Terry Lambert wrote: > > > 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. Huh? ``To what shell?'' -- ``None of them.'' Am i in the wrong movie? > This has only to do with ourder of revoke() > processing when revoke() is a result of on-to-off-DCD transition. The foreground process group gets properly signalled. I've been using a FreeBSD-based ISP for long enough to know that it works. > > 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. No. It hasn't. ksh properly shuffles each job into a separate process group (unlike the non-jobcontrol prehistoric /bin/sh). It *purposely* kills all its children before dying. That's why you can achieve the csh's default behaviour by logging out with ``kill -9 $$'' -- the background process groups will then behave like they do in csh. > The Bourne shell specifically distinguished children this way via > the "nohup" mechansim. The csh implies "nohup" for all subshells, No. The children are still sensitive to a SIGHUP if you send it to them. The shell doesn't send it to them iff they are _running in background_ when the shell exits. (Stopped jobs will be reaped nevertheless.) This is why the manual says that running background jobs are ``effectively nohuped''. They are not really nohuped. > > So, take out the SVR3's above (for not having job control at all), use > > csh, and retry your tests. > SVR3 supported "nohup". Sure, but that's another game. See above. > > 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, That's no reason for curses to never assume an error could not happen. Errors can happen for more reasons. Errors are to be caught. Anything else is sloppy programming. There used to be a Usenix paper titled: Can't happen or /* NOTREACHED */ or Real Programs dump Core. -- 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?19970927145007.HB02894>