qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] RFC: running the user interface in a thread ...


From: Eric Blake
Subject: Re: [Qemu-devel] RFC: running the user interface in a thread ...
Date: Tue, 19 Jan 2016 22:05:33 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0

On 01/19/2016 08:28 AM, Daniel P. Berrange wrote:
> On Tue, Jan 19, 2016 at 02:01:47PM +0100, Gerd Hoffmann wrote:
>>   Hi,
>>
>>> That, and so the UI can use localization without corrupting other
>>> threads that MUST use the C locale (QMP parsing/output of floating point
>>> is particularly important to get right with '.' instead of ',' for a
>>> decimal separator).
>>
>> A quick look at the setlocale manpage doesn't make clear whenever
>> threads can have different locales or not.
> 
> glibc has per-thread locales, but this isn't guaranteed portable across
> unix platforms.

POSIX requires it, but not all the world has caught up to POSIX.

> We could enable per-thread localization on Linux builds
> but disable it on other platforms.

Sure, that's a reasonable compromise.

> 
>> Related:  Possibly we should move UIs to another *process* instead?
>> At least the ones which use a UI toolkit (i.e. sdl, gtk, cocoa).
> 
> Is the worth the effort ? The majority of mgmt apps use spice/vnc which
> is already out of process. Will the people do use SDL/GTK/Coca backends,
> be doing so in a scenario where moving the UI to a separate process is
> a benefit to them ?  I'm not saying we shouldn't separate the UI to
> another process, just that we should consider whether there's other
> things todo in QEMU UI layer that are a better payoff for the userbase.

I haven't done enough UI programming to have an informed opinion here.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]