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

[Avi Kivity]

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