This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Thread-, Signal- and Cancellation-safety documentation
- From: Alexandre Oliva <aoliva at redhat dot com>
- To: Torvald Riegel <triegel at redhat dot com>
- Cc: KOSAKI Motohiro <kosaki dot motohiro at gmail dot com>, Rich Felker <dalias at aerifal dot cx>, Florian Weimer <fweimer at redhat dot com>, libc-alpha <libc-alpha at sourceware dot org>
- Date: Sun, 19 May 2013 04:31:40 -0300
- Subject: Re: Thread-, Signal- and Cancellation-safety documentation
- References: <orppym7okv dot fsf at livre dot home> <20130326064347 dot GL20323 at brightrain dot aerifal dot cx> <515AB073 dot 9000500 at redhat dot com> <20130402134325 dot GO20323 at brightrain dot aerifal dot cx> <CAHGf_=q=2sM0C5kLazsVWiRfRvO0NX-sDRX2-SfoJkkCix9vzQ at mail dot gmail dot com> <1368788825 dot 3054 dot 3182 dot camel at triegel dot csb>
On May 17, 2013, Torvald Riegel <triegel@redhat.com> wrote:
> * There's no clear definition of whether "thread-safe" is about...
There's a clear definition of the specified behavior for each function,
so âfunction F is safe to callâ ought to mean âF behaves as specifiedâ.
What other constrains *need* to be set forth in the standard so as to
allow for a broad past, present and future diversity of implementations,
while still giving enough guarantees to users for the standard to be
usable?
I've already argued in the other message I just posted that there's a
downside to overspecifying and overconstraining implementations of a
standard. Now it remains to be shown that the current amount of
constraining in the relevant standards is insufficient, or that it would
be beneficial overall to add more ordering and/or atomicity constraints.
--
Alexandre Oliva, freedom fighter http://FSFLA.org/~lxoliva/
You must be the change you wish to see in the world. -- Gandhi
Be Free! -- http://FSFLA.org/ FSF Latin America board member
Free Software Evangelist Red Hat Brazil Compiler Engineer