This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
Attached is an update. This, internally, disambiguates NORMAL and DEFAULT. We don't have NORMAL initializers, so all NORMAL mutexes must be initialized through settype(). Thus, we can do give NORMAL mutexes a new internal type there. When we call gettype for NORMAL-like mutexes, we just translate back. So far so good. The next wishlist item is to be able to explicitly initialize DEFAULT mutexes through settype(). If such code would still use the public DEFAULT type value, you'd always initialize to NORMAL, effectively. (PTHREAD_MUTEX_INITIALIZER and all mutexattr initializations with NULL would still result in DEFAULT.) To avoid this, the patch introduces a new public DEFAULT type, and translates this one to a new internal alias for DEFAULT (with a value of zero, ie. what the initializer still uses). But the problem of this is that we'd then need to translate it back to match settype() inputs; if we have an old binary with a new libc calling gettype() for a default-initialized mutex, it will get the new DEFAULT value back, which is meaningless to the binary. So this can't work. In general, gettype() currently can't be used anyway to distinguish between a NORMAl and a DEFAULT mutex, because they use the same value internally. One could argue that programs should check equality to both (ie, a mutex could be NORMAL, DEFAULT, or both because DEFAULT's undefined behavior allows the deadlock). But I guess most programs would just do an if (==NORMAL) else (== DEFAULT) kind of thing. Or should we just not try to support explicit initialization of DEFAULT mutexes *via settype()* and just make them NORMAL mutexes by default? This way, we wouldn't need to introduce a new public PTHREAD_MUTEX_DEFAULT value, and could still disambiguate DEFAULT from NORMAL when the initialization happens via static initializers or default mutex attributes (ie, NULL parameter). Thoughts?
Attachment:
patch
Description: Text document
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |