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