Date: Fri, 11 Dec 1998 14:53:04 -0500 (EST) From: "John W. DeBoskey" <jwd@unx.sas.com> To: archie@whistle.com (Archie Cobbs) Cc: peter.edwards@isocor.ie, dillon@apollo.backplane.com, jwd@unx.sas.com, freebsd-current@FreeBSD.ORG Subject: Re: inetd: realloc/free bug Message-ID: <199812111953.OAA19914@bb01f39.unx.sas.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 just had to say in front of me:
> Peter Edwards writes:
> > > It's not trivial if you want to guarantee that no signals are missed.
> > > There's no way atomically to: unblock signals and call select().
> >
> > Hmm. I must be twisted.
> > 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) */
> }
>
> But there are probably smarter ways to do it than this.
>
> -Archie
Oh, I don't know. I have a task management system where I feed
all signals back through pipes. My process is basically one
large state machine, and using select() to determine that a
sigchld just occurred let's me deal with children as a state
which can then forward to other states as required depending
on exit status, etc. It let's me treat remote children death
the same as local children death (ie: The remote signal handler
simply write()s to a pipe that points back to the task manager).
Overall, I believe this to be a rather elegant solution to handling
out-of-band transaction information.
-John
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?199812111953.OAA19914>