Date: Mon, 28 Sep 1998 11:57:50 +0200 (SAT) From: Graham Wheeler <gram@cdsec.com> To: grog@lemis.com (Greg Lehey) Cc: hackers@FreeBSD.ORG Subject: Re: The inetd realloc problem: an observation Message-ID: <199809280957.LAA11960@cdsec.com> In-Reply-To: <19980928132438.N25391@freebie.lemis.com> from "Greg Lehey" at Sep 28, 98 01:24:38 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> On Tuesday, 22 September 1998 at 15:27:49 +0200, Graham Wheeler wrote:
> >>
> >> On Sep 22, 1:44pm, Greg Lehey wrote:
> >>> Subject: The inetd realloc problem: an observation
> >>> I trust that everybody knows what I mean by the "inetd realloc"
> >>> problem: after some undefined event inetd behaves in an unfriendly
> >>> manner towards incoming requests, possibly confusing the clients
> >>> enough to make them turn away in disgust.
> >>
> >> I'm can't say I'm suprised after looking at the code, which does all sorts
> >> of dangerous things like malloc() from within signal handlers. There are
> >> some things it is safe to do within a signal handler, but most things aren't.
> >> Probably the best thing to do is to rewrite the code so that the signal
> >> handlers just set a flag (of type sig_atomic_t), which gets checked in
> >> the mainline code where it is safe to to the complicated stuff.
> >
> > I've just changed the source so that all three signal handlers just set
> > flags, and the flags are tested at the start of the main processing loop
> > and the old handlers called if necessary. It will be interesting to see
> > if this improves things.
>
> Any experience yet?
So far it seems to be working fine. My approach was not as sophisticated as
the one suggested by others (writing values into a pipe). I just changed
each handler to set a volatile int variable, modified the main select() to
use a 60 second timeout, and before the select, did a:
while (any signal handler flag set)
{
if (sigchld_flag) { sigchld_flag = 0; do_old_sigchld_handler(); }
...
}
It may be possible that this is vulnerable to race conditions, but thus
far it has been working fine.
Perhaps it would be better to increment/decrement the flags, rather than
set/clear them...?
--
Dr Graham Wheeler E-mail: gram@cdsec.com
Citadel Data Security Phone: +27(21)23-6065/6/7
Internet/Intranet Network Specialists Mobile: +27(83)253-9864
Firewalls/Virtual Private Networks Fax: +27(21)24-3656
Data Security Products WWW: http://www.cdsec.com/
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199809280957.LAA11960>