Messages in this thread | | | Date | Fri, 08 Feb 2013 18:55:54 -0500 | From | Sasha Levin <> | Subject | Re: [PATCH 09/11] liblockdep: support using LD_PRELOAD |
| |
On 02/08/2013 05:43 AM, Jamie Iles wrote: > On Thu, Feb 07, 2013 at 09:31:22AM -0500, Sasha Levin wrote: >> On 02/07/2013 05:28 AM, Jamie Iles wrote: >>>> +int pthread_rwlock_init(pthread_rwlock_t *rwlock, >>>>> + const pthread_rwlockattr_t *attr) >>>>> +{ >>>>> + if (ll_pthread_rwlock_init == NULL) >>>>> + init_preload(); >>> Why is this one special, doesn't init_preload being a constructor make >>> this redundant? >> >> I was testing it on different things, and stumbled on an interesting case: >> when pthread_mutex was taken from the constructor of a different module. >> >> In that case, the other constructor would try to init the mutex and take >> a lock, but we would segfault because we haven't resolved the pthread >> symbols yet ourselves (since our constructor was yet to be called). > > Okay, that makes sense, but shouldn't we do this for all of the lock > operations? pthread locks can be statically initialized and they are > initializaed lazily on the first access so I think that this could > happen on any of the lock operations.
hmm... I've had it only in init() because I thought it doesn't make sense to actually lock/unlock in constructor code, but yeah - better safe than sorry.
Thanks, Sasha
| |