httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dean Gaudet <dgau...@arctic.org>
Subject Re: "locale" project
Date Fri, 19 Dec 1997 19:22:42 GMT


On Fri, 19 Dec 1997, [KOI8-R] áÎÄÒÅÊ þÅÒÎÏ× wrote:

> In first place I don't understand why Apache itself (not modules) need to
> be under locale != "C", do you have some examples? I.e. if you need just
> localized strftime() output just fork once with specific locale at the
> Apache startup and pass all locale-specific requests to forked process. 
> Shared memory or mmap gives almost no overhead in this situation.  In this
> model we have just one process per locale used. I am against runtime
> locales switching inside Apache core because it cause too much overhead. 

I'm against runtime switching of locales as well.  In fact all we need is
the C locale and whatever other locale the local user wants -- I listed
two PRs where the user wants their own locale for things like mod_php and
mod_include when formating dates for sending to the client.  Since we need
only C and "one other" locale I think we could get away with implementing
specifically the set of locale functions we use, and using the system's
own setlocale() for whatever "true" locale the user wants to use.  What a
mess.

An alternative is to say to these users "tough, C is all we support".  Can
some of the mod_php folk explain maybe why users need the locale
functionality?  I think I know why... but a specific example would be good
:)

> > The C library is poorly designed, POSIX isn't helping it at all.  We
> > pretty much have to replace all the string and allocation functions
> > because we need better resource management and more functionality.  It's a
> > similar step to start replacing the locale functions because we need
> > better locale management. 
> 
> It is almost impossible to replace locale functions, although locale calls
> are mostly standartized per POSIX, even call arguments (locale names) are
> not standartized and locale data itself is _very_ different from system to
> system...

Yeah... you're right.  But we could provide locale C specific functions --
and maybe we can even do it in a way that a server can be built with the
option of using only locale C, or using C and one other. 

> I understand your portability intention but it leades to Apache Operating
> System(TM) as result running on dedicated machine with nothing else. It
> seems there is no good solution of this problem.  I hope it not happens in
> nearest future....

It sucks... but we're not the first to go down this road.  qmail uses
essentially nothing from man section 3, it has a library of its own which
is more suited to writing secure applications.  I'd like to see Apache
move this way as well... and as we replace string and alloc functions we
venture further and further away from libc.

> > One more thing to add:  locale is a global setting, in a threaded port we
> > can't switch locales at all. 
> 
> Maybe will be good to ask someone from POSIX committie about their
> locale-related plans.

Yeah, but I always get confused by all the different subcommittees. 

Hey C++ folks, is this solved in any magic C++ class library?  Ick, I
don't want to bloat us further by going to C++ ;) 

Dean


Mime
View raw message