This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Update on freeze status of glibc 2.18?
- From: Rich Felker <dalias at aerifal dot cx>
- To: Roland McGrath <roland at hack dot frob dot com>
- Cc: Torvald Riegel <triegel at redhat dot com>, Carlos O'Donell <carlos at redhat dot com>, GNU C Library <libc-alpha at sourceware dot org>, Ryan Arnold <rsa at us dot ibm dot com>, "Joseph S. Myers" <joseph at codesourcery dot com>, Siddhesh Poyarekar <siddhesh at redhat dot com>, andi <andi at firstfloor dot org>
- Date: Fri, 21 Jun 2013 22:04:13 -0400
- Subject: Re: Update on freeze status of glibc 2.18?
- References: <20130614224427 dot 4B2532C077 at topped-with-meat dot com> <51BF3CF8 dot 1010901 at redhat dot com> <1371494971 dot 16968 dot 21574 dot camel at triegel dot csb> <20130617193649 dot 7B5872C08D at topped-with-meat dot com> <1371503900 dot 16968 dot 21902 dot camel at triegel dot csb> <20130619224234 dot 5AC132C10E at topped-with-meat dot com> <1371733830 dot 964 dot 1089 dot camel at triegel dot csb> <20130620230930 dot 6F21E2C135 at topped-with-meat dot com> <1371775236 dot 964 dot 3432 dot camel at triegel dot csb> <20130621231410 dot B0A142C14C at topped-with-meat dot com>
On Fri, Jun 21, 2013 at 04:14:10PM -0700, Roland McGrath wrote:
> > I haven't found anything clarifying whether they should behave like
> > DEFAULT or like NORMAL.
>
> I don't understand what distinction you have in mind here. POSIX defines
> NORMAL basically by saying it doesn't necessarily do any of the things that
> the other POSIX-standard types do. (I don't think it can properly be
No, it provides explicit requirements for NORMAL. They were previously
expressed in paragraph form; now TC1 has a table:
http://pubs.opengroup.org/onlinepubs/9699919799/functions/pthread_mutex_lock.html
> construed to say that it behaves any particular way on deadlock, such as
> deadlocking; EDEADLK is specified as a "may fail". Perhaps that is
No, it is specified as "shall fail" for some types of mutexes and "may
fail" for the rest.
> debatable; it probably merits an interpretation request.) It defines
> DEFAULT as the implementation's choice of one of the POSIX-standard types
> (including NORMAL), or some other implementation-defined type.
I'm a little bit concerned about whether there is a requirement, if
DEFAULT has the same numeric value as one of the standard types, that
it behave the same as that type.
> > What I don't understand in your plan is how we deal with the case that
> > we have a PTHREAD_MUTEX_INITIALIZER in a program built against new glibc
> > headers, but executed with an older glibc version. In this case, the
> > new type values coming from the initializer wouldn't be understood by
> > the old pthread_mutex_lock(), for example.
>
> That's a very good point! I knew there was some reason I felt the need to
> add that caveat about thinking thoroughly. ;-)
The PTHREAD_MUTEX_INITIALIZER macro is not going to be changed. That's
the whole point.
Rich