From mboxrd@z Thu Jan  1 00:00:00 1970
From: paulmck@linux.vnet.ibm.com (Paul E. McKenney)
Date: Tue, 5 Apr 2011 21:48:31 -0700
Subject: [ltt-dev] [rp] [PATCH RFC urcu 1/2] Provide
 pthread_atfork-friendly interfaces
In-Reply-To: <20110405052424.GF3125@linux.vnet.ibm.com>
References: <20110323183635.GA21074@linux.vnet.ibm.com>
	<1300905482-21272-1-git-send-email-paulmck@linux.vnet.ibm.com>
	<BLU0-SMTP27EA77FA8AD9A87249AAF496BE0@phx.gbl>
	<20110405041127.GB3125@linux.vnet.ibm.com>
	<20110405043237.GA11707@feather>
	<20110405052424.GF3125@linux.vnet.ibm.com>
Message-ID: <20110406044831.GA3296@linux.vnet.ibm.com>

On Mon, Apr 04, 2011 at 10:24:24PM -0700, Paul E. McKenney wrote:
> On Mon, Apr 04, 2011 at 09:32:37PM -0700, Josh Triplett wrote:
> > On Mon, Apr 04, 2011 at 09:11:27PM -0700, Paul E. McKenney wrote:
> > > On Fri, Apr 01, 2011 at 04:52:50PM -0400, Mathieu Desnoyers wrote:
> > > > * Paul E. McKenney (paulmck at linux.vnet.ibm.com) wrote:
> > > > > Provides call_rcu_before_fork() and call_rcu_after_fork_parent() to
> > > > > go with the existing call_rcu_after_fork_child().
> > > > > 
> > > > > Signed-off-by: Paul E. McKenney <paulmck at linux.vnet.ibm.com>
> > > > > ---
> > > > >  README          |    4 ++++
> > > > >  urcu-call-rcu.c |   29 ++++++++++++++++++++++++++++-
> > > > >  2 files changed, 32 insertions(+), 1 deletions(-)
> > > > > 
> > > > > diff --git a/README b/README
> > > > > index f7f0dec..56e98d7 100644
> > > > > --- a/README
> > > > > +++ b/README
> > > > > @@ -204,3 +204,7 @@ Interaction with fork()
> > > > >  	liburcu-bp, which is designed to handle fork() by calling
> > > > >  	rcu_bp_before_fork, rcu_bp_after_fork_parent and
> > > > >  	rcu_bp_after_fork_child.
> > > > > +
> > > > > +	Applications that use call_rcu() are required to invoke
> > > > > +	call_rcu_after_fork_child() from the child process after a
> > > > > +	successful fork() system call that is not followed by exec().
> > > > 
> > > > Should you say something about the before hook, and after hook in the
> > > > parent too ?
> > > 
> > > Good point, fixed as follows:
> > > 
> > > diff --git a/README b/README
> > > index 56e98d7..3e23120 100644
> > > --- a/README
> > > +++ b/README
> > > @@ -205,6 +205,8 @@ Interaction with fork()
> > >  	rcu_bp_before_fork, rcu_bp_after_fork_parent and
> > >  	rcu_bp_after_fork_child.
> > >  
> > > -	Applications that use call_rcu() are required to invoke
> > > -	call_rcu_after_fork_child() from the child process after a
> > > -	successful fork() system call that is not followed by exec().
> > > +	Applications that use call_rcu() and that fork() without
> > > +	doing an immediate exec() must take special action.  The parent
> > > +	must invoke call_rcu_before_fork() before the fork() and
> > > +	call_rcu_after_fork_parent() after the fork().  The child
> > > +	process must invoke call_rcu_after_fork_child().
> > 
> > Ideally, this shold explicitly suggest pthread_atfork.  Even better,
> > consider adding a urcu_pthread_atfork_init or similar, or an init
> > function which takes flags so that you can do this by default and have a
> > flag to disable it.
> 
> Yep, you can use pthread_atfork() and a later enhancement will allow you
> to tell the initialization functions to call pthread_atfork() for you.
> But this does not work with rcu_bp, since you can just start invoking
> API members without calling any initialization function.  So both are
> required.

And I did add a mention of pthread_atfork() to the README file.  ;-)

							Thanx, Paul