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
