Re: [Qemu-devel] [RFC next] ui: Split main() in two to not have Cocoa hijack it

[Andreas Färber]

Am 30.05.2012 11:00, schrieb Paolo Bonzini:
> Il 28/05/2012 20:18, Andreas Färber ha scritto:
>> Only call into cocoa.m when determined necessary by QEMU's option
>> handling. Avoids redoing all option parsing in ui/cocoa.m:main()
>> and constantly missing new options like -machine accel=qtest.
>>
>> Move function declarations to a new ui.h header to avoid recompiling
>> everything when the new UI-internal function interface changes.
>>
>> Handle the -psn option properly in vl.c.
>>
>> Replace the faking of command line options for user-selected disk
>> image with proper API usage.
> 
> This is nice. :)
> 
> But the split between main/main2 is ugly.
> 
> Is it possible to run the main loop (basically everything starting at
> the creation of the NSAutoreleasePool on) in a separate thread?

No.

> cocoa_main starts the thread and sits on a condition variable waiting
> for applicationDidFinishLaunching: to be called.
> 
> applicationDidFinishLaunching: signals that condition variable, then
> goes on a loop like
> 
>     qemu_mutex_lock(&qemu_cocoa_mutex);
>     globalCons = 0;
>     localCons = globalCons;
> 
>     for (;;) {
>         while (!exiting && localCons == globalCons) {
>             qemu_cond_wait(&qemu_cocoa_cond, &qemu_cocoa_mutex);
>         }
>         if (exiting) {
>             break;
>         }
> 
>         /* we can behave as if we held the global mutex, we
>            know the iothread is waiting for us */
>         ... content of cocoa_refresh ...
> 
>         globalProd++;
>         qemu_cond_broadcast(&qemu_cocoa_mutex);
>     }
>     qemu_mutex_unlock(&qemu_cocoa_mutex);
>     [NSApp stop];
> 
> and cocoa_refresh only handles the rendez-vous:
> 
>     qemu_mutex_lock(&qemu_cocoa_mutex);
>     localProd = globalProd;
>     globalCons++;
>     qemu_cond_broadcast(&qemu_cocoa_mutex);
>     while (localProd == globalProd) {
>         qemu_cond_wait(&qemu_cocoa_cond, &qemu_cocoa_mutex);
>     }
>     qemu_mutex_unlock(&qemu_cocoa_mutex);
>     vga_hw_update();

I'd have to investigate this, but the main issue seemed to be that we
cannot *inline* the startup code into QEMU's main() as it is. If we
manage to split it at some sensible point, we can switch to a
multithreaded model. However from what I remember, going as low-level as
creating our own main loop would require re(verse)-engineering Cocoa
code iirc.

Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg