This is the mail archive of the libc-hacker@sources.redhat.com mailing list for the glibc project.

Note that libc-hacker is a closed list. You may look at the archives of this list, but subscription and posting are not open.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

__libc_lock_lock_recursive et al


There seem to be some locks declared with plain __libc_lock_define et al
but that actually need to be recursive locks for things to work right.
For example, _dl_load_lock.  In that case, there is even a comment saying
that it must be a recursive lock, but it doesn't use the right macros.
What's up with that?

I really think it's unacceptable to have all these broken uses of
libc-lock.h when it is so clear what is the right way for them to be.
How was this allowed to happen in the first place?

It is gratuitous overhead to use recursive locks when normal locks suffice,
so I object to making __libc_lock_lock et al always do recursive locks.
That was never the specification of the interface and the users of the
interface never should have been written to presume it.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]