From owner-freebsd-current Tue Mar 11 07:15:56 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id HAA10468 for current-outgoing; Tue, 11 Mar 1997 07:15:56 -0800 (PST) Received: from ui-gate.utell.co.uk (ui-gate.utell.co.uk [194.200.4.253]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id HAA10462 for ; Tue, 11 Mar 1997 07:15:51 -0800 (PST) Received: from shift.lan.awfulhak.org (shift.utell.net [97.3.0.21]) by ui-gate.utell.co.uk (8.7.6/8.7.3) with ESMTP id PAA27287; Tue, 11 Mar 1997 15:15:40 GMT Received: from shift.lan.awfulhak.org (localhost [127.0.0.1]) by shift.lan.awfulhak.org (8.8.5/8.8.5) with ESMTP id PAA27630; Tue, 11 Mar 1997 15:17:00 GMT Message-Id: <199703111517.PAA27630@shift.lan.awfulhak.org> X-Mailer: exmh version 1.6.9 8/22/96 To: =?KOI8-R?B?4c7E0sXKIP7F0s7P1w==?= cc: Brian Somers , Brian Somers , FreeBSD-current Subject: Re: ppp In-reply-to: Your message of "Tue, 11 Mar 1997 12:45:56 +0300." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 11 Mar 1997 15:17:00 +0000 From: Brian Somers Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > On Tue, 11 Mar 1997, Brian Somers wrote: > > > Right, but as I pointed out, just about anything that uses Log* will > > call LogFlush() and malloc(), and malloc() isn't necessarily the only > > problem - there are almost definitely other recursion suseptable > > functions running around too, ones that aren't nice enought to tell us > > when they can't handle things. I suggest we put back the pending > > stuff in all cases except SIGSEGV (which we don't trap). With the > > usage of the "caused" variable in handle_signals fixed (I agree, that > > was a pretty terrible mistake), there should not be any other > > problems. > > Few minutes ago I send you message with subject "ppp & signals pending" > not seeing this your message... Please don't miss it, here I explain > my position mainly about SIGALRM and its pending. To summarize it > I can say that I agree with restoring pending for SIGALRM, but some > additional measurement must be done before. I havn't seen this mail yet - I'm at work at the moment, so it'll probably be at home by the time I get there. > > Ok, so if I put (a fixed) sig.c back in there, could I ask you to do > > some testing ? I was thinking of: > > > > void handle_signals() { > > int sig; > > int had; > > > > had = caused; > > if (had) > > for (sig=0; sig<__MAXSIG; sig++) > > if (had&(1< > caused &= ~(1< > (*handler[sig])(sig+1); > > } > > } > > This way you lost _number_ of signals which may come. Since all signals > mapped to single bit in "caused" bitmask, here can be f.e. 10 or more > similar signals, but only one time signal handler will be executed. You > need to replace "caused" bitmask with "int caused[__MAXSIG];" and count > true number of signals come: caused[sig]++ (decrease it when handler was > executed: caused[sig]--). BTW, why you use own __MAXSIG when standard > NSIG is available from signal.h? Ok, I can re-produce the right number of signals. I don't know why this is really needed, but I agree that it's more correct to handle things the right number of times. The reason I used __MAXSIG was because the code wasn't written to be able to handle NSIG > 32. > -- > Andrey A. Chernov > > http://www.nagual.ru/~ache/ > I'll send you a copy of the code with the above before commiting. I'd be grateful if you could examine it for anything horrible. I'll read your other mail first. Thanks. -- Brian Don't _EVER_ lose your sense of humour !