[ltt-dev] [rp] [PATCH urcu 4/4] Provide cleanup interfaces for per-CPU and per-thread call_rcu threads

[Paul E. McKenney]

On Wed, Mar 09, 2011 at 12:51:17PM -0500, Mathieu Desnoyers wrote:
> * Paolo Bonzini (pbonzini at redhat.com) wrote:
> > On 03/09/2011 05:54 PM, Mathieu Desnoyers wrote:
> > > I'm just concerned about the execution order of the atfork callbacks. If
> > > we provide the callbacks directly, then the application can take care to
> > > call the various callbacks in a known order (e.g. first execute the
> > > call_rcu functions, and then the RCU lib functions).
> > > 
> > > If we use atfork, the order will be pretty much random, and I'm not sure
> > > I like that.
> > 
> > From the man page:
> > 
> >        The  order  of calls to pthread_atfork() is significant. The parent and
> >        child fork handlers shall be called in the order  in  which  they  were
> >        established  by  calls  to pthread_atfork().  The prepare fork handlers
> >        shall be called in the opposite order.
> > 
> > It looks like call_rcu's atfork should be done first.
> 
> And we would have to guarantee the order by numbering the call_rcu and
> urcu constructors with reverse priority order, am I correct ? It sounds
> like a recipe for an hidden bug, and I would rather prefer to let the
> application deal with this.
> 
> Moreover, in the case of URCU-bp, the application does not have to use
> pthreads (only the UST user-space tracer library does): we are relying
> on direct override of the fork() symbol. So if we ever want to use
> call_rcu in libust, having direct access to the before/after fork
> symbols gives us more control on the call order.

OK, fair enough, I will provide the three functions and document how
they can be used.

							Thanx, Paul