From owner-freebsd-current Tue Mar 11 12:08:37 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id MAA06047 for current-outgoing; Tue, 11 Mar 1997 12:08:37 -0800 (PST) Received: from awfulhak.demon.co.uk (awfulhak.demon.co.uk [158.152.17.1]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id MAA06029; Tue, 11 Mar 1997 12:08:23 -0800 (PST) Received: from awfulhak.demon.co.uk (localhost.lan.awfulhak.org [127.0.0.1]) by awfulhak.demon.co.uk (8.8.5/8.8.5) with ESMTP id UAA06847; Tue, 11 Mar 1997 20:04:18 GMT Message-Id: <199703112004.UAA06847@awfulhak.demon.co.uk> X-Mailer: exmh version 1.6.9 8/22/96 To: =?KOI8-R?B?4c7E0sXKIP7F0s7P1w==?= cc: brian@freebsd.org, FreeBSD-current Subject: Re: ppp & signals pending In-reply-to: Your message of "Tue, 11 Mar 1997 12:19:31 +0300." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 11 Mar 1997 20:04:18 +0000 From: Brian Somers Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > Brian, here some thoughts about signals pending in ppp and possible > restoring your sig.c functionality: > > All signals separated by following categories: > > 1) Fatal signals which can't be pended (they was pended in old version > which cause dead loop). Everything that's trapped with a call to Hangup() is fatal, but I suspect that HUP was causing the malloc() recursion. > 2) SIGALRM can be pended with great care, there is too many functions > (lqr, fsm, ...) which assume that they called via regular intervals (f.e. > "... send LQR every %d.%d secs"). Time difference between pended SIGALRM > and not pended variant must be not greater then minimal accuracy expected. > This things are relatively hard to control and measure, that is why I > prefer not pend SIGALRM at all and remove sig.c code instead of fixing it, > but if you can show that needed accuracy is reached, you can restore > pending of SIGALRM back. Tricky. As you say, it's difficult to test this stuff. Trying to prove it with statistics will be tricky too, AFAIK, the stdio libs won't recurse too well and they call malloc() to boot. Would you be interested if I sent you a copy of timer.c/main.c that remembers when it's called and dumps statistics on exit ? > 3) Other signals can be pended safely (including kill signals), but only > for main loop, not for execv (they was pended for execv in old variant, > also it looks like cosmetique thing with current implementation). The stuff before exec doesn't really matter - I left it pending for tidyness - it clears the caused bit/element and then calls signal(). I don't mind if this stuff stays out. > -- > Andrey A. Chernov > > http://www.nagual.ru/~ache/ > > -- Brian , Don't _EVER_ lose your sense of humour....