This is the mail archive of the
libc-ports@sources.redhat.com
mailing list for the libc-ports project.
Re: [PATCH] Unify pthread_once (bug 15215)
- From: Rich Felker <dalias at aerifal dot cx>
- To: Torvald Riegel <triegel at redhat dot com>
- Cc: GLIBC Devel <libc-alpha at sourceware dot org>, libc-ports <libc-ports at sourceware dot org>
- Date: Thu, 9 May 2013 11:56:13 -0400
- Subject: Re: [PATCH] Unify pthread_once (bug 15215)
- References: <1368024237 dot 7774 dot 794 dot camel at triegel dot csb> <20130508175132 dot GB20323 at brightrain dot aerifal dot cx> <1368046046 dot 7774 dot 1441 dot camel at triegel dot csb> <20130508212502 dot GF20323 at brightrain dot aerifal dot cx> <1368088765 dot 7774 dot 1571 dot camel at triegel dot csb> <20130509140245 dot GI20323 at brightrain dot aerifal dot cx> <1368112468 dot 7774 dot 2082 dot camel at triegel dot csb>
On Thu, May 09, 2013 at 05:14:28PM +0200, Torvald Riegel wrote:
> > > I agree that the absence of a proper memory model makes reasoning about
> > > some of this hard. I guess it would be best if POSIX would just endorse
> > > C11's memory model, and specify the intended semantics in relation to
> > > this model where needed.
> >
> > Agreed, and I suspect this is what they'll do. I can raise the issue,
> > but perhaps you'd be better at expressing it. Let me know if you'd
> > rather I do it.
>
> I have no idea how the POSIX folks would feel about this. After all, it
> would create quite a dependency for POSIX. With that in mind, trying to
> resolve this isn't very high on my todo list. If people would think
> that this would be beneficial for how we can deal with POSIX
> requirements, or for our users to understand the POSIX requirements
> better, I can definitely try to follow up on this. If you want to go
> ahead and start discussing with them, please do so (please CC me on the
> tracker bug).
POSIX is aligned with ISO C, and since the current version of ISO C is
now the 2011 version, Issue 8 should be aligned to the 2011 version of
the C standard. I don't think the issue is whether it happens, but
making sure that the relevant text gets updated so that there's no
ambiguity as to whether it's compatible with the new C standard and
not placing unwanted additional implementation constraints like it may
be doing now.
Rich