This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: libstdc++, generic locale configuration, and c++0x
- From: Jonathan Wakely <jwakely dot gcc at gmail dot com>
- To: Doug Semler <dougsemler at gmail dot com>
- Cc: "libstdc++" <libstdc++ at gcc dot gnu dot org>
- Date: Mon, 7 Jun 2010 14:59:48 +0100
- Subject: Re: libstdc++, generic locale configuration, and c++0x
- References: <AANLkTinGdh6X4yKymGJbAo0jcCNir9Q8dp_HXdeMSo09@mail.gmail.com> <76EA67BD-2158-45A7-BFBA-1DFBD8E35FC0@oracle.com> <AANLkTinmVgtteP0heyCXtNG0imq33f9SFJlSq29ToT4p@mail.gmail.com> <AANLkTinnwj1obWy49K2vYy6VHnhs4HdsPZYyPGAmZDU0@mail.gmail.com> <AANLkTimPueQld0SPWAhomNO5ODDH00OA7h8RuXvrsFeo@mail.gmail.com> <AANLkTinroxt6T3ibYKAZRw254RD2ABCgCny-D3AZcsB5@mail.gmail.com>
On 7 June 2010 14:18, Doug Semler wrote:
>
> Well, there's a trade off here: ?The affected code is in the parsing
> and formatting of date/time, floating point, and money formats to and
> from strings. ?Is the performance loss so great in these small number
> of cases that it prevents the inclusion of the guard? ?Incorrect
> results and/or crashes due to the lack of thread safety in these
> sections of code, IMO, is much more problematic than the effect of
> locks on performance.
Agreed, but any change introducing locks would need to be carefully
considered, and maybe made configurable.
> At this time, any target that uses the generic
> implementation (or glibc <= 2.2) must put guards at the user code
> level around anything that potentially calls these sections --- and
> due to the way the documentation is written, programmers probably are
> unaware of this requirement.
Indeed. Even if the library uses a lock internally, any user code
which changes the locale can still cause problems, because that user
code won't share the lock. That's a lesser problem though.
> (NB: This could probably mitigated slightly by changing the locale
> only if necessary --- e.g. when the detected locale is not the "C"
> locale...it looks like some of the config/locale/gnu code does this).
My prototype checks whether the setlocale call can be skipped. It
still locks the mutex though; I think the lock could be skipped too,
because another thread would only see a different locale if a user
changed it, and in that case the lock doesn't help anyway.
> It's either that or rewrite those functions in such a way that they do
> not rely on the C library and the global locale...which I am sure is
> quite a bit of work.
Yes, quite a bit :-)