Re: Detecting if UI thread is running, and creating a UI thread
Re: Detecting if UI thread is running, and creating a UI thread
- Subject: Re: Detecting if UI thread is running, and creating a UI thread
- From: glenn andreas <email@hidden>
- Date: Fri, 2 Mar 2007 14:18:27 -0600
On Mar 2, 2007, at 10:28 AM, Justin Armstrong wrote:
Hi Glenn,
Thanks for your help!
glenn andreas wrote:
On Mar 2, 2007, at 5:16 AM, Justin Armstrong wrote:
The problem is that we cannot assume the caller of CreateJob() is
actually a Cocoa/Carbon app with a UI thread. If the caller is a
command line app then there will be no UI thread to handle the
event loop and respond to the button click events. So...
How can i determine if a UI thread is running?
There is no such thing as a "UI thread" - you've made some
assumptions here that are going to get you stuck.
There are actually two different things going on here.
First, all UI needs to be done on the main thread, be it Carbon or
Cocoa. There is always a main thread (so in Cocoa it's always
safe to do performOnMainThread: et al). If you do UI from a non-
main thread, it will crash sooner or later (with "sooner" being
more likely).
By "UI thread" i just mean the thread which runs the event loop.
This seems to be called the "main thread" in Mac documentation, so
i'm wondering if this means that it is hardwired to be the first
thread of the process. Obviously a standard Cocoa/Carbon app will
run the event loop in its first thread. In the case of a Cocoa app
the event loop is started by the call to NSApplicationMain() from
the boilerplate main() function. What I'd like to know is if it is
possible for a command line type program which has not started an
event loop to spawn a second thread and then make that the "main
thread". Is it just a case of calling NSApplicationMain in the new
thread instead?
Well, as far as Cocoa is concerned, all UI needs to be done in the
main thread. This does not imply that calling NSApplicationMain from
a secondary thread is going to work or not, but consider that there
is going to be code that will use "performSelectorOnMainThread:(etc)"
which is documented to:
The main thread is the one in which the main run loop is run, which
usually means the one in which the NSApplication object receives
events
Note that it uses the word "usually" (so there explicitly could be
cases where NSApp is going to receive events on a different thread),
nor does it say anything about "the thread where NSApplicationMain is
called from". Worse, there is quite possibly code that checks
pthread_main_np() and uses the pthread concept of "main
thread" (which in your case would explicitly not be the same thread
as NSApplicationMain was called).
So I'd say that not only is it not documented to work, but there is a
good chance it won't (and if it does, it may not in the next release
of the OS).
If you have a command line utilities that needs some (minor) user
interaction, the Carbon Notification Manager should provide the
simple basics. If you want a full UI, you will either need a
secondary helper application (that your command line util can launch
and interact with using something like DO), or you should just make a
real application.
Glenn Andreas email@hidden
<http://www.gandreas.com/> wicked fun!
quadrium2 | build, mutate, evolve, animate | images, textures,
fractals, art
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden