On Apr 21, 2009, at 9:10 PM, Brian Tietz wrote:
I'm working on a cross-platform framework, and am trying to finish
up a parallel but portable message dispatch mechanism in the
framework when its main thread is running in NSApplication. To this
end, I'm using CFRunLoopSourceCreate/CFRunLoopAddSource as the
framework message trigger because I can safely trigger the source
from other threads using that mechanism. It is working nicely,
except for the quit sequencing. In Linux/GTK, the analogous
mechanism is installing the read end of a pipe using g_io_add_watch,
writing to the pipe when a message is posted to my framework, and it
works perfectly.
For the Cocoa implementation, I have implemented an
applicationShouldTerminate app delegate notification handler which
posts a quit request to my framework (triggering it by way of the
CFRunLoopSource) and returns NSTerminateCancel. That last detail is
very unfortunate, but if I return NSTerminateLater the app goes into
a modal state and neglects the CFRunLoop, with my framework's quit
request not being received as a consequence.
It's not neglecting the run loop. It's just running it in a different
mode. The documentation for NSTerminateLater says it's running it in
the NSModalPanelRunLoopMode. So, just add your run loop source in
that same mode, in addition to the default mode. Then, you can use
NSTerminateLater and all of your headaches vanish.
Cheers,
Ken
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
