tech-userlevel archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: ctype, chrtbl, rune tables and POSIX2008
On Wed, Jan 18, 2012 at 10:42:23PM +0000, YAMAMOTO Takashi wrote:
> >> i'm not sure if it's a good idea because
> >>
> >> - uselocale is acutally being used by third party code in the wild.
> >>
> >> - uselocale is in standard.
> >>
> >> - sometimes uselocale is the only choice.
> >> eg. when calling a library which internally uses locale-sensitive
> >> functions.
> >
> > The problem is that it adds the TLS access overhead for all the
> > locale-sensitive functions.
>
> isn't it avoidable with a global
> uselocale_has_ever_been_used_for_this_process variable?
I don't know. I just saw a report on the FreeBSD lists that the
uselocale() stuff add a significant overhead (78%?) to some common
operations. It requires a lot more work e.g. for ctype(3) and in fact,
it breaks the ABI (silently). That sounds like a good reason to not
support it.
> > Further complications are added by VAX and
> > Sun2 still not supporting TLS. It seems like a strong hack around for
> > broken code.
>
> can't they use a plain setspecific?
That makes the code more even more ugly.
> >> >> is the rest of his patch ok for you?
> >> >
> >> > Looking at the latest version, I don't agree with using _ all over the
> >> > place. I think it would help to clean up dead code first -- is there a
> >> > good reason for keeping CITRUS optional? Getting rid of that helps for
> >> > all the patches in the area (ctype, multi-locale etc). After having only
> >> > a single implementation, we can easily go over each function set and
> >> > merge it individually.
> >>
> >> the size of libc is the only reason to have it optional i'm aware of.
> >> but i even don't know how much it makes libc smaller/bigger.
> >
> > joerg@britannica:/tmp/with-citrus$ size libc.so.12.179
> > text data bss dec hex filename
> > 1136427 47232 65752 1249411 131083 libc.so.12.179
> >
> > joerg@britannica:/tmp/without-citrus$ size libc.so.12.179
> > text data bss dec hex filename
> > 1101773 41984 63832 1207589 126d25 libc.so.12.179
> >
> > That's AMD64 with Clang. Does the small difference really justify the
> > complexity?
>
> thanks for providing numbers.
> it seems not worth the complexity to me.
> but i guess an x86-only guy like me is not a right person to judge. :-)
>
> i remembered another possible problem; the size of statically linked binaries.
> eg. a single printf pulled in a lot of locale stuff.
Let's take bin/cat as example:
text data bss dec hex filename
163956 4396 19912 188264 2df68 with-citrus/cat
147756 4136 19912 171804 29f1c without-citrus/cat
Joerg
Home |
Main Index |
Thread Index |
Old Index