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

[Mathieu Desnoyers]

* 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.

Thanks,

Mathieu

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