Re: performSelectorOnMainThread and other thread notifications
Re: performSelectorOnMainThread and other thread notifications
- Subject: Re: performSelectorOnMainThread and other thread notifications
- From: Shawn Erickson <email@hidden>
- Date: Thu, 12 Feb 2004 09:53:00 -0800
On Feb 12, 2004, at 9:29 AM, Glen Low wrote:
Shawn:
On Feb 12, 2004, at 3:51 AM, Glen Low wrote:
Hi all,
I saw the recent thread [pun intended] on
performSelectorOnMainThread and it seems just what the doctor
ordered for Graphviz file change notifications. However, what is the
minimal level of initialization I have to do on the calling thread
before I can use it?
Is it:
A. a naked pthread
B. a NSThread (Cocoa set to multithreaded)
C. a NSThread with an NSAutoreleasePool
D. a NSThread with a NSRunLoop running?
If you are using Cocoa frameworks in a secondary thread, regardless
of how it was created, you should have a NSAutoreleasePool wrapping
the Cocoa code to catch any autoreleased objects.
NSThreads are wrappers for pthreads IIRC. Calling currentThread in
any thread should work and generate a NSThread instance that wraps
your thread. So in reality any of the above should be valid ways to
call "performSelectorOnMainThread". Note you do not need an NSThread
instance to call the method just send it to any object in your
application.
The worry is, if I create a naked pthread without calling any other
Cocoa function in it except performSelectorOnMainThread, it's not
going to work. And even if I call currentThread and it automagically
makes a NSThread for me, it's obviously not going to have a
NSAutoreleasePool in it?
NSThread is just a object used to describe your current thread it isn't
its own thread, so you don't need an autorelease pool in it but you
should have a pool in place around calls into the Cocoa framework.
So the safe thing to do it something like the following...
Secondary thread:
...code...
NSAutoreleasePool *pool = [[NSAutorreleasePool alloc] init];
[someObject performSelectorOnMainThread:@selector(doSomething)
withObject:nil waitUntilDone:NO];
[pool release];
...more code...
Another issue is, I have to run a kqueue and kevent on a separate
thread, and these are fairly low-level BSD constructs. A kqueue can
wait on several sorts of kernel events like a file change, etc. Now
I want my main thread to tell the kqueue thread to stop looking at a
file, for example, when the corresponding document is closed, but to
avoid polling it has to wait on a pipe or a signal. Can I do any of
these things from the main thread in a thread-safe manner?
It is hard to suggest a more solid example without a better
understanding of how your secondary thread(s) are created and run,
etc.
Do you have one thread waiting per file or a single thread waiting on
kqueue for all files? Are your secondary threads using a run loop or
can they (add the kqueue as a source)?
I haven't decided whether to have one thread per file or one thread
for all files.
The secondary threads cannot be running an NSRunLoop since I don't
want to poll the kqueue, I want to block on it waiting for a file
system change (hmm.. unless NSRunLoops support such things). But if I
block waiting for a change, how will the main thread interrupt it, say
when a document is closed and no longer needs to be monitored?
NSRunLoops don't really poll, it blocks waiting on an event to come in
from one of its registered event sources and then check the sources as
needed. In other words it doesn't spin in a loop wasting CPU time. Note
almost all apps in Mac OS X have a run loop (NSRunLoop/CFRunLoop) for
its core event loop.
If you can get your kqueue attached as a source for the run loop you
could also attach a source (say an NSPort) that can be used to talk
with your secondary thread (while it is running the run loop). I need
to read up on kqueues myself so I cannot help you much and don't want
to go to far an mislead ya... so take what I am saying with a grain of
salt.
-Shawn
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.