Re: [Qemu-devel] Ongoing changes to the displaying code

[Avi Kivity <avi@redhat.com>]

Ian Jackson wrote:
> Avi Kivity writes ("Re: [Qemu-devel] Ongoing changes to the displaying code"):
>   
>> Instant messaging clients seem to have solved this without resorting to 
>> multiple processes.
>>     
>
> Multiple processes are not a `resort'.  And of course an IM client
> needs to do a lot less than qemu, and the things that it does do are
> much less hairy.
>   

In terms of not shutting down the app when the close button is pressed, 
a good single process solution exists.  I agree that qemu's usage of 
signals is problematic.  Perhaps switching to real-time signals instead 
of SIGALRM and SIGIO will help.

Any other hairy things in qemu?

>>> I think that's a better route to go for this sort of thing.  If you 
>>> think it's generally useful, I think it'd also be worthwhile to host 
>>> within the QEMU project.  I just don't think it's the right thing to 
>>> add into QEMU directly.
>>>       
>> Or it could be done as a separate executable that links to a libqemu.so; 
>> the standard qemu binary could be implemented the same way.
>>     
>
> I'm not sure how well qemu's processing model will fit in with GUI
> toolkits.  I wouldn't trust Qt and Gtk not to make expectations which
> are reasonable in a `general purpose' program but not sensible in
> qemu's context.
>   

You would run qemu and the gui in different threads.  If the signal 
problem is resolved, I don't see any other issues.

-- 
error compiling committee.c: too many arguments to function