Re: Gtk+ print support - request for feedback

Alexander Larsson wrote:
On Fri, 2006-03-03 at 13:59 -0500, Morten Welinder wrote:
What's the status of thread safety?  Last I looked at cups it was
not thread safe due to calling setlocale, and there was little
understanding as to why that was a problem.

(And recall that just about any gtk+ program is at least
minimally threaded.)

Hmm, cups still seems to be changing the locale. Both for parsing floats
in the ppd with "." as separator, and in cupsLangGet() (where it calls
setlocale(LC_ALL, NULL) if the locale wasn't already set).

The "setlocale(LC_ALL, NULL)" call is safe - it returns the current
value.  The only time we set the locale is when the user calls
cupsLangDefault() and hasn't already called setlocale()...

We *do* currently save/restore the LC_CTYPE locale settings right now,
but I *think* that part can be removed now (will check) since we've
changed how the message catalogs are loaded.

We can avoid calling anything that results in cupsLangGet(), but not the
float parsing.
Michael, is there any chance that this will be fixed in cups? The way
gtk+ does threadsafe locale-independent float parsing is this: (I wrote this code, so if you want to use it in cups I'm ok with
re-licensing it in a suitable way)

I'd rather avoid introducing a hack like this if we can avoid it.
Also, we use sscanf() in the PPD code to parse multiple float values,
so it will be necessary to do something a little more invasive in our
code... :(

The man page for setlocale() says nothing about thread safety, but
given how all of the other standard C calls work I'm frankly shocked
that setting the locale in one thread affects the others.  Is this
just a bug on Linux, or is it a general problem on other operating

Michael Sweet, Easy Software Products           mike at easysw dot com
Internet Printing and Publishing Software

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]