On Tue, Nov 24, 2009 at 11:50 AM, Paul Pluzhnikov <[email protected]>wrote:
> On Tue, Nov 24, 2009 at 10:54 AM, Arun Sharma <[email protected]> wrote: > > > Executing apply_reg_state with the lock held is a problem only for > > UNW_CACHE_GLOBAL. > > With lock *not* held. Correct. > Yes - I meant with lock not held. > > I have tried to set UNW_CACHE_PER_THREAD as I was debugging this > race, but that caused crashes I didn't understand; perhaps I should > revisit that. > > Hmm, I don't see how it could work at all in current code :( > > Doesn't using UNW_CACHE_PER_THREAD require that unw_local_addr_space > in x86*/Ginit.c be made a per-thread variable? Otherwise, all threads > will share that global, but will not lock it. > You're right. This part is broken for dwarf. We'll need to fix it along the lines of src/ia64/Gscript.c > > I'm inclined to apply the more conservative fix #1 until we have more > data > > on the cost of the memcpy vs using UNW_CACHE_PER_THREAD. > > My concern with fix#1 is that it reduces concurrency in a hot function > (apply_reg_state) -- we have CPUs to burn! > Agree that fix#1 is suboptimal. The choice is really between fix #2 and a fixed UNW_CACHE_PER_THREAD. -Arun
_______________________________________________ Libunwind-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/libunwind-devel
