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

[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?
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();

(Disclaimer, I used Cocoa exactly once).

Paolo