From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:55379) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZUXJ8-0003VZ-P9 for qemu-devel@nongnu.org; Wed, 26 Aug 2015 05:47:51 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZUXJ5-0006qa-JZ for qemu-devel@nongnu.org; Wed, 26 Aug 2015 05:47:50 -0400 Received: from mx1.redhat.com ([209.132.183.28]:53647) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZUXJ5-0006qR-Bh for qemu-devel@nongnu.org; Wed, 26 Aug 2015 05:47:47 -0400 From: Markus Armbruster References: <20150818235754.GA31625@igalia.com> <87r3mtq9wx.fsf@blackfin.pond.sub.org> <87oahwr4x1.fsf@blackfin.pond.sub.org> <55DB51DC.6070704@redhat.com> <87d1ybpzul.fsf@blackfin.pond.sub.org> <20150826092236.GC21787@redhat.com> Date: Wed, 26 Aug 2015 11:47:44 +0200 In-Reply-To: <20150826092236.GC21787@redhat.com> (Daniel P. Berrange's message of "Wed, 26 Aug 2015 10:22:36 +0100") Message-ID: <87vbc2qt33.fsf@blackfin.pond.sub.org> MIME-Version: 1.0 Content-Type: text/plain Subject: Re: [Qemu-devel] QEMU produces invalid JSON due to locale-dependent code List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Daniel P. Berrange" Cc: Alberto Garcia , Gerd Hoffmann , qemu-devel@nongnu.org "Daniel P. Berrange" writes: > On Wed, Aug 26, 2015 at 11:13:00AM +0200, Alberto Garcia wrote: >> On Tue 25 Aug 2015 09:54:42 AM CEST, Markus Armbruster wrote: >> >> >> (D) Run in a controlled mixed locale >> >> GTK runs completely in the locale determined by setlocale() (since it >> >> never has to display raw JSON) >> >> We fix our JSON output code to use thread-specific locale >> >> manipulations to (temporarily) switch to C locale before printing JSON >> >> >> >> that way, GTK still shows full German formatting for any localized >> >> message in the GUI that happens to print numbers, but the JSON output >> >> (which is independent of the GUI) also behaves correctly as a C-only >> >> entity. >> > >> > Switching back to C locale whenever some unwanted locale-dependency >> > breaks the code is problematic, because it involves finding all the >> > places that break, iteratively (euphemism for "we debug one breakage >> > after the other, adding temporary locale switches as we go). >> >> For some cases we probably don't even need to switch the locale. For the >> JSON case cannot we just easily convert the QFloat into a string >> ourselves without using printf's "%f" ? > > FWIW, libvirt had this exact same problem with formatting doubles for > JSON while non-C locales are in effect. We used the glibc thread-local > locale support, and fallback to some sick string munging in non-glibc > case: [...] For QEMU, I doubt sick string munging just to support GUI localization on losing systems is worthwhile. >> That doesn't invalidate however your point. >> >> > I'd feel much better about confining GTK in its own thread, and >> > setting only that thread's locale. >> >> I haven't digged much into that part of the QEMU code, but if my >> assumptions are true I think we would need at least: >> >> - A separate GMainContext with its own main loop >> - Making sure that all the code that touches the UI runs from that >> thread. >> >> This is in principle possible, but I fear that we might be opening a can >> of worms. > > Agreed, my experiance is that you should always run GTK in the main > thread and never try todo anything more clever with threads + GTK. > It has always ended in tears for me - even if you think you have it > working on your system, you'll inevitably find a different version > of GTK where it has broken. It just isn't worth the pain to try to > run anything GTK related in a non-main thread. If we can't move GTK out of the main thread, we need to move everything else out. One more option: instead of switching back to the C locale around identified troublemakers (and then chase them down one by one, bug by bug), switch away from it just around the GUI. Thread-locally of course. Callbacks may require extra care. We should've stayed out of the GUI business.