All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ian Campbell <ijc@hellion.org.uk>
To: Bernd Petrovitsch <bernd@firmix.at>
Cc: linux-kernel@vger.kernel.org,
	Arjan van de Ven <arjan@infradead.org>,
	lgb@lgb.hu
Subject: Re: OT: fork(): parent or child should run first?
Date: Wed, 11 Jan 2006 14:05:16 +0000	[thread overview]
Message-ID: <1136988316.6517.8.camel@localhost.localdomain> (raw)
In-Reply-To: <1136987743.6547.122.camel@tara.firmix.at>

On Wed, 2006-01-11 at 14:55 +0100, Bernd Petrovitsch wrote:
> On Wed, 2006-01-11 at 13:49 +0000, Ian Campbell wrote:
> > On Wed, 2006-01-11 at 14:25 +0100, Bernd Petrovitsch wrote:
> > > Then this leaves the race if an old pid is reused in a newly created
> > > process before the last instances of that pid is cleaned up.
> > 
> > The PID won't be available to be re-used until the signal handler has
> > called waitpid() on it?
> 
> Yes.
> But ATM the signal handler calls waitpid() and stores the pid in a
> to-be-cleaned-pids array (at time X).
> The main loop at some time in the future (say at time X+N) walks through
> the to-be-cleaned-pids array and cleans them from the active-childs
> array.

yuk... I'd say the application is a bit dumb for calling waitpid before
it is actually prepared for the pid to be reclaimed. 

A possible solution would be to also defer the waitpid until the main
loop cleanup function, perhaps flagging the entry in the child array as
not-active between the signal and that time or moving the pid from the
active to an inactive array in the signal handler.

Ian.
-- 
Ian Campbell
Current Noise: Sloth - Into The Sun

To err is human,
To purr feline.
		-- Robert Byrne


  reply	other threads:[~2006-01-11 14:04 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-01-11 12:37 OT: fork(): parent or child should run first? Gábor Lénárt
2006-01-11 12:51 ` Arjan van de Ven
2006-01-11 13:02   ` Gábor Lénárt
2006-01-11 13:25     ` Bernd Petrovitsch
2006-01-11 13:49       ` Ian Campbell
2006-01-11 13:55         ` Bernd Petrovitsch
2006-01-11 14:05           ` Ian Campbell [this message]
2006-01-11 15:19             ` linux-os (Dick Johnson)
2006-01-12  1:33           ` David Schwartz
2006-01-12  1:38     ` Kurt Wall
2006-01-12 17:23       ` Hugh Dickins
2006-01-12 20:19         ` Gábor Lénárt
2006-01-11 13:34   ` Roland Kuhn
2006-01-11 17:11     ` Lee Revell
2006-01-11 13:03 ` Miquel van Smoorenburg
2006-01-11 13:08 ` Jan-Benedict Glaw
2006-01-12  1:33 ` David Schwartz

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1136988316.6517.8.camel@localhost.localdomain \
    --to=ijc@hellion.org.uk \
    --cc=arjan@infradead.org \
    --cc=bernd@firmix.at \
    --cc=lgb@lgb.hu \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.