SIGCHLD race condition?

Nicolas Williams Nicolas.Williams at ubsw.com
Thu Oct 4 04:35:08 EST 2001


No, Paul meant to open a pipe when there are no child fildes left to
select for and all you have to do is wait for client input or the child
to die -- since select() can't do the waiting, the next best thing is
for the SIGCHLD handler to write into this pipe whose read end you can
select() for.

It's a neat trick. SIGCHLD arrives and the handler reaps the child and
writes a byte to this place holder pipe, then, when the select() loop is
entered you come out because there's that byte in the pipe, you check
the child terminated variable and you exit. No more race condition.

Nico


On Wed, Oct 03, 2001 at 01:28:27PM -0500, mouring at etoh.eviladmin.org wrote:
> 
> By the pipe solution I assume you mean #define USE_PIPE 1 .. We already
> support Pipes for platforms that need them.
> 
> - Ben
> 
> On Wed, 26 Sep 2001, Paul Menage wrote:
> 
> > >
> > >
> > >On Wed, 26 Sep 2001, Paul Menage wrote:
> > >
> > >> - Switch to using queued signals for network readiness events, then use
> > >> sigtimedwait() or similar instead of select(). I imagine that this would
> > >> be a fairly major overhaul of the networking code.
> > >>
> > >
> > >And how does one emulate sigtimedwait() for those older platforms that
> > >lack it?  I don't remember seeing it listed in the NeXTStep manpages.
> >
> > So scrap that idea then - it's more of a change than I'd think people
> > would want anyway.
> >
> > How about the pipe solution? That should be relatively portable.
> >
> > Paul
> >
> >
--

Visit our website at http://www.ubswarburg.com

This message contains confidential information and is intended only 
for the individual named.  If you are not the named addressee you 
should not disseminate, distribute or copy this e-mail.  Please 
notify the sender immediately by e-mail if you have received this 
e-mail by mistake and delete this e-mail from your system.

E-mail transmission cannot be guaranteed to be secure or error-free 
as information could be intercepted, corrupted, lost, destroyed, 
arrive late or incomplete, or contain viruses.  The sender therefore 
does not accept liability for any errors or omissions in the contents 
of this message which arise as a result of e-mail transmission.  If 
verification is required please request a hard-copy version.  This 
message is provided for informational purposes and should not be 
construed as a solicitation or offer to buy or sell any securities or 
related financial instruments.




More information about the openssh-unix-dev mailing list