From owner-freebsd-current Tue Mar 11 01:32:57 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id BAA09199 for current-outgoing; Tue, 11 Mar 1997 01:32:57 -0800 (PST) Received: from sequent.kiae.su (sequent.kiae.su [193.125.152.6]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id BAA09189; Tue, 11 Mar 1997 01:32:51 -0800 (PST) Received: by sequent.kiae.su id AA05028 (5.65.kiae-2 ); Tue, 11 Mar 1997 12:19:59 +0300 Received: by sequent.KIAE.su (UUMAIL/2.0); Tue, 11 Mar 97 12:19:59 +0300 Received: (from ache@localhost) by nagual.ru (8.8.5/8.8.5) id MAA00612; Tue, 11 Mar 1997 12:19:35 +0300 (MSK) Date: Tue, 11 Mar 1997 12:19:31 +0300 (MSK) From: =?KOI8-R?B?4c7E0sXKIP7F0s7P1w==?= To: brian@freebsd.org, FreeBSD-current , brian@awfulhak.demon.co.uk Subject: ppp & signals pending Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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). 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. 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). -- Andrey A. Chernov http://www.nagual.ru/~ache/