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 ([email protected]) 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 <[email protected]>
> > > > ---
> > > > 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.
Thanx, Paul
_______________________________________________
ltt-dev mailing list
[email protected]
http://lists.casi.polymtl.ca/cgi-bin/mailman/listinfo/ltt-dev
