On Sat, Sep 6, 2008 at 4:24 AM, Petr Salinger <[EMAIL PROTECTED]> wrote: > Imagine function in a shared library foo which takes as argument > pthread_mutex_t and does usual: > > pthread_mutex_lock() > do some work > pthread_mutex_unlock() > > And a program bar, which uses foo. Inside bar is a static initialized lock. > The foo might be (re)compiled against NPTL, while bar would be still > compiled against LT. Therefore check_and_reset() should be called as long as > any installed (debian) package have not been recompiled against NPTL. The > overhead of check_and_reset() looks very small, it should be no problem at > all. The harder part is to determine each place, where > check_and_reset() should be called. It have to be in all places, > where static initialized lock might be passed for the 1st time, > i.e. it should be in pthread_mutex_lock(), but not in > pthread_mutex_unlock().
I reviewed the compatibility provided by glibc for the pthread_cond_t change in 2.3.2, and I see no such guarantee that an address of a pthread_cont_t in an old binary can be safely passed to a library rebuilt against the new libc . When upstream changed pthread_cond_t, making it larger, they versioned the interface, and the old function mallocs a pointer to the new structure and call the new function with the newly malloc'd structure. I think 99% of all situations are covered by providing an old function. Guarding the new function against a mixed ABI use seems like a performance penalty with an unknown benefit. Clearly if upstream glibc didn't think it was usefull, should we also ignore this scenario? I have compat patches in testing on my SMP parisc64 box. I should have some results by next week. Cheers, Carlos. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
