* Paul E. McKenney ([email protected]) wrote:
> On Thu, Sep 29, 2011 at 01:59:12PM -0400, Mathieu Desnoyers wrote:
> > * Paul E. McKenney ([email protected]) wrote:
> > > On Wed, Sep 28, 2011 at 04:34:32PM +0800, Lai Jiangshan wrote:
> > > > Signed-off-by: Lai Jiangshan <[email protected]>
> > > > ---
> > > > urcu-call-rcu-impl.h | 6 ++++++
> > > > 1 files changed, 6 insertions(+), 0 deletions(-)
> > > >
> > > > diff --git a/urcu-call-rcu-impl.h b/urcu-call-rcu-impl.h
> > > > index 65c1c7a..3c68ae7 100644
> > > > --- a/urcu-call-rcu-impl.h
> > > > +++ b/urcu-call-rcu-impl.h
> > > > @@ -686,6 +686,12 @@ void call_rcu_after_fork_child(void)
> > > > default_call_rcu_data = NULL;
> > > > (void)get_default_call_rcu_data();
> > > >
> > > > + /* Cleanup call_rcu_data pointers before used */
> > > > + maxcpus = 0;
> > > > + free(per_cpu_call_rcu_data);
> > > > + per_cpu_call_rcu_data = NULL;
> > >
> > > Good catch! I would expect that the number of CPUs would be the
> > > same for the child as it was for the parent, but doesn't hurt to
> > > make the child start over.
> > >
> > > > + thread_call_rcu_data = NULL;
> > >
> > > Isn't thread_call_rcu_data already NULL due to the child being a new
> > > thread and the C initialization-to-zero rules?
> >
> > #include <unistd.h>
> > #include <stdio.h>
> >
> > int __thread a;
> >
> > int main()
> > {
> > int pid;
> >
> > a = 1;
> > pid = fork();
> > if (pid > 0) {
> > printf("parent val %d\n", a);
> > return 0;
> > } else {
> > printf("child val %d\n", a);
> > return 0;
> > }
> > }
> >
> > compudj@thinkos:/tmp$ gcc -o test test.c
> > compudj@thinkos:/tmp$ ./test
> > parent val 1
> > child val 1
> >
> > AFAIK, the c initialization to zero rules apply to exec(), not fork.
> > Here we are taking care of after-fork in the child, in cases where the
> > child is not doing an exec.
> >
> > Does that make more sense ?
>
> I would think that the forked child would be a new thread, but obviously
> not! I stand corrected.
It all makes more sense when you consider the following paragraph of
pthread_atfork(3):
To understand the purpose of pthread_atfork, recall that fork(2) dupli‐
cates the whole memory space, including mutexes in their current lock‐
ing state, but only the calling thread: other threads are not running
in the child process. The mutexes are not usable after the fork and
must be initialized with pthread_mutex_init in the child process. This
is a limitation of the current implementation and might or might not be
present in future versions.
Thanks,
Mathieu
>
> Thanx, Paul
>
> > Thanks,
> >
> > Mathieu
> >
> >
> > >
> > > Thanx, Paul
> > >
> > > > +
> > > > /* Dispose of all of the rest of the call_rcu_data structures.
> > > > */
> > > > cds_list_for_each_entry_safe(crdp, next, &call_rcu_data_list,
> > > > list) {
> > > > if (crdp == default_call_rcu_data)
> > > > --
> > > > 1.7.4.4
> > > >
> >
> > --
> > Mathieu Desnoyers
> > Operating System Efficiency R&D Consultant
> > EfficiOS Inc.
> > http://www.efficios.com
> >
>
--
Mathieu Desnoyers
Operating System Efficiency R&D Consultant
EfficiOS Inc.
http://www.efficios.com
_______________________________________________
ltt-dev mailing list
[email protected]
http://lists.casi.polymtl.ca/cgi-bin/mailman/listinfo/ltt-dev
