From owner-freebsd-hackers Tue Sep 22 06:23:42 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id GAA00374 for freebsd-hackers-outgoing; Tue, 22 Sep 1998 06:23:42 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from citadel.cdsec.com (citadel.cdsec.com [192.96.22.18]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id GAA00365 for ; Tue, 22 Sep 1998 06:23:14 -0700 (PDT) (envelope-from gram@cdsec.com) Received: (from nobody@localhost) by citadel.cdsec.com (8.8.8/8.6.9) id PAA11148; Tue, 22 Sep 1998 15:29:23 +0200 (SAST) Received: by citadel via recvmail id 11146; Tue Sep 22 15:29:12 1998 From: Graham Wheeler Message-Id: <199809221327.PAA06772@cdsec.com> Subject: Re: The inetd realloc problem: an observation To: Don.Lewis@tsc.tdk.com (Don Lewis) Date: Tue, 22 Sep 1998 15:27:49 +0200 (SAT) Cc: hackers@FreeBSD.ORG In-Reply-To: <199809221302.GAA17355@salsa.gv.tsc.tdk.com> from "Don Lewis" at Sep 22, 98 06:02:23 am X-Mailer: ELM [version 2.4 PL25-h4.1] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > 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. -- 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