Re: Gtk+ print support - request for feedback

["Gustavo J. A. M. Carneiro" <gjc inescporto pt>]

On Seg, 2006-03-06 at 08:27 -0500, Michael Sweet wrote:
> 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... :(

  This code has also been incorporated into Python, since 2.4.  You can
find here a version a bit glib-ish:

http://svn.python.org/view/python/trunk/Python/pystrtod.c?rev=42382&view=auto

  Regards,

-- 
Gustavo J. A. M. Carneiro
<gjc inescporto pt> <gustavo users sourceforge net>
The universe is always one step beyond logic.