Date: Fri, 11 Dec 1998 11:57:59 -0800 (PST) From: Archie Cobbs <archie@whistle.com> To: freebsd-current@FreeBSD.ORG Subject: Re: inetd: realloc/free bug Message-ID: <199812111957.LAA27876@bubba.whistle.com> In-Reply-To: <199812111940.LAA27652@bubba.whistle.com> from Archie Cobbs at "Dec 11, 98 11:40:58 am"
next in thread | previous in thread | raw e-mail | index | archive | help
Archie Cobbs writes: > > What horror results from doing this in a signal handler? On e-paper, it > > seems to give the desired effect, but does a return from a signal > > handler implicitly call sigreturn(2) when it returns? And if so, is > > there anything that requires this to happen? > > I guess I was thinking in terms of the event library model; that is, > you don't handle the signal event in the signal handler (because in > general the event handler could call malloc(), etc), but rather you > simply set a flag (call it "signalFlag"). > > The race condition is getting a signal between the first and second > lines below: > > sigprocmask(SIG_UNBLOCK ..) /* unblock signals */ > r = select(...) /* wait for event */ > sigprocmask(SIG_BLOCK ..) /* block signals */ > > if (signalFlag || r > 0) { > ... /* handle event(s) */ > } OK, if you call the signal "event" handler from within the actual signal handler because of a signal received bewtween lines 1 and 2, that's OK because you know you're not in a recursive malloc() situation. So I guess that would work. -Archie ___________________________________________________________________________ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199812111957.LAA27876>