Being thread-safe is not the same thing as deferring to the main thread though.
Here are a couple of examples of how things can go wrong, depending on the implementation of Cocoa:
- applicationWillTerminate is a notification, and as such will run in the main thread, but will applicationShouldTerminate also be called only from the main thread? If not, is it safe to show the alert in verifyQuit?
- is the secondary thread still in terminate: when applicationWillTerminate runs, and is it waiting for applicationWillTerminate to finish? If so, qemu_thread_join will deadlock (because the waited thread will not exit until applicationWillTerminate returns)
In both cases the problem is not thread-unsafety of Cocoa, but thread-unsafety of the QEMU application delegate.
Paolo
Regards,
Akihiko Odaki
>
> Paolo
>
> Regards,
>> Akihiko Odaki
>>
>>>
>>> - here:
>>>
>>> /*
>>> * Nothing more to do in the QEMU thread, ask the application
>>> * to exit.
>>> */
>>> dispatch_async(dispatch_get_main_queue(), ^{
>>> [NSApp terminate: nil];
>>> });
>>>
>>> - in verifyQuit:
>>>
>>> if([alert runModal] == NSAlertSecondButtonReturn) {
>>> with_iothread_lock(^{
>>> shutdown_action = SHUTDOWN_ACTION_POWEROFF;
>>> qemu_system_shutdown_request(SHUTDOWN_CAUSE_HOST_UI);
>>> });
>>> }
>>> /* and just return void */
>>>
>>> - applicationShouldTerminate: should be just
>>>
>>> if (qatomic_read(&qemu_main_terminating)) {
>>> return NSTerminateNow;
>>> } else {
>>> dispatch_async(dispatch_get_main_queue(), ^{
>>> [self verifyQuit];
>>> });
>>> }
>>> return NSTerminateCancel;
>>>
>>> - applicationWillTerminate: can be just the qemu_thread_join
>>>
>>> Paolo
>>
>>
>