From owner-freebsd-current  Fri Dec 11 11:53:25 1998
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Received: (from majordom@localhost)
          by hub.freebsd.org (8.8.8/8.8.8) id LAA18861
          for freebsd-current-outgoing; Fri, 11 Dec 1998 11:53:25 -0800 (PST)
          (envelope-from owner-freebsd-current@FreeBSD.ORG)
Received: from lamb.sas.com (lamb.sas.com [192.35.83.8])
          by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA18856
          for <freebsd-current@FreeBSD.ORG>; Fri, 11 Dec 1998 11:53:22 -0800 (PST)
          (envelope-from jwd@unx.sas.com)
Received: from mozart (mozart.unx.sas.com [192.58.184.8])
	by lamb.sas.com (8.9.1/8.9.1) with SMTP id OAA09724;
	Fri, 11 Dec 1998 14:53:04 -0500 (EST)
Received: from bb01f39.unx.sas.com by mozart (5.65c/SAS/Domains/5-6-90)
	id AA15086; Fri, 11 Dec 1998 14:53:04 -0500
Received: (from jwd@localhost)
	by bb01f39.unx.sas.com (8.9.1/8.9.1) id OAA19914;
	Fri, 11 Dec 1998 14:53:04 -0500 (EST)
	(envelope-from jwd)
From: "John W. DeBoskey" <jwd@unx.sas.com>
Message-Id: <199812111953.OAA19914@bb01f39.unx.sas.com>
Subject: Re: inetd: realloc/free bug
In-Reply-To: <199812111940.LAA27652@bubba.whistle.com> from Archie Cobbs at "Dec 11, 98 11:40:58 am"
To: archie@whistle.com (Archie Cobbs)
Date: Fri, 11 Dec 1998 14:53:04 -0500 (EST)
Cc: peter.edwards@isocor.ie, dillon@apollo.backplane.com, jwd@unx.sas.com,
        freebsd-current@FreeBSD.ORG
X-Mailer: ELM [version 2.4ME+ PL38 (25)]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

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