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