From mboxrd@z Thu Jan  1 00:00:00 1970
From: compudj@krystal.dyndns.org (Mathieu Desnoyers)
Date: Wed, 13 Apr 2011 17:26:58 -0400
Subject: [ltt-dev] [PATCH RFC urcu 1/4] Provide
	pthread_atfork-friendly	interfaces
In-Reply-To: <BLU0-SMTP72AEB7B7D5D738CC54CA4896AA0@phx.gbl>
References: <20110413035110.GA26549@linux.vnet.ibm.com>
	<1302666735-26723-1-git-send-email-paulmck@linux.vnet.ibm.com>
	<BLU0-SMTP72AEB7B7D5D738CC54CA4896AA0@phx.gbl>
Message-ID: <BLU0-SMTP6298A8F6F7A3BACE77C82096AA0@phx.gbl>

* Mathieu Desnoyers (compudj at krystal.dyndns.org) 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().
> 
> Is it possible that we should also mention the before fork and after
> fork parent here ? If there is a reason why it is not needed, then we
> should state this explicitly, because this is a little surprising.

Please disregard this question, it looks like your patch 3/4 takes care
of it.

Thanks,

Mathieu

> 
> Thanks,
> 
> Mathieu
> 
> > diff --git a/urcu-call-rcu.c b/urcu-call-rcu.c
> > index bb56dbb..665f20c 100644
> > --- a/urcu-call-rcu.c
> > +++ b/urcu-call-rcu.c
> > @@ -566,13 +566,40 @@ void free_all_cpu_call_rcu_data(void)
> >  }
> >  
> >  /*
> > + * Acquire the call_rcu_mutex in order to ensure that the child sees
> > + * all of the call_rcu() data structures in a consistent state.
> > + * Suitable for pthread_atfork() and friends.
> > + */
> > +void call_rcu_before_fork(void)
> > +{
> > +	call_rcu_lock(&call_rcu_mutex);
> > +}
> > +
> > +/*
> > + * Clean up call_rcu data structures in the parent of a successful fork()
> > + * that is not followed by exec() in the child.  Suitable for
> > + * pthread_atfork() and friends.
> > + */
> > +void call_rcu_after_fork_parent(void)
> > +{
> > +	call_rcu_unlock(&call_rcu_mutex);
> > +}
> > +
> > +/*
> >   * Clean up call_rcu data structures in the child of a successful fork()
> > - * that is not followed by exec().
> > + * that is not followed by exec().  Suitable for pthread_atfork() and
> > + * friends.
> >   */
> >  void call_rcu_after_fork_child(void)
> >  {
> >  	struct call_rcu_data *crdp;
> >  
> > +	/* Re-initialize the mutex. */
> > +	if (pthread_mutex_init(&call_rcu_mutex, NULL) != 0) {
> > +		perror("pthread_mutex_init");
> > +		exit(-1);
> > +	}
> > +
> >  	/*
> >  	 * Allocate a new default call_rcu_data structure in order
> >  	 * to get a working call_rcu thread to go with it.
> > -- 
> > 1.7.3.2
> > 
> 
> -- 
> Mathieu Desnoyers
> Operating System Efficiency R&D Consultant
> EfficiOS Inc.
> http://www.efficios.com
> 
> _______________________________________________
> ltt-dev mailing list
> ltt-dev at lists.casi.polymtl.ca
> http://lists.casi.polymtl.ca/cgi-bin/mailman/listinfo/ltt-dev
> 

-- 
Mathieu Desnoyers
Operating System Efficiency R&D Consultant
EfficiOS Inc.
http://www.efficios.com