Date: Tue, 11 Mar 1997 15:17:00 +0000 From: Brian Somers <brian@shift.lan.awfulhak.org> To: =?KOI8-R?B?4c7E0sXKIP7F0s7P1w==?= <ache@nagual.ru> Cc: Brian Somers <brian@awfulhak.demon.co.uk>, Brian Somers <brian@utell.co.uk>, FreeBSD-current <current@freebsd.org> Subject: Re: ppp Message-ID: <199703111517.PAA27630@shift.lan.awfulhak.org> In-Reply-To: Your message of "Tue, 11 Mar 1997 12:45:56 %2B0300." <Pine.BSF.3.95q.970311122719.666A-100000@nagual.ru>
index | next in thread | previous in thread | raw e-mail
> 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<<sig)) {
> > caused &= ~(1<<sig);
> > (*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
> <ache@null.net>
> 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 <brian@awfulhak.demon.co.uk> <brian@freebsd.org>
<http://www.awfulhak.demon.co.uk>;
Don't _EVER_ lose your sense of humour !
help
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199703111517.PAA27630>