Re: performSelectorOnMainThread and other thread notifications
Re: performSelectorOnMainThread and other thread notifications
- Subject: Re: performSelectorOnMainThread and other thread notifications
- From: Glen Low <email@hidden>
- Date: Fri, 13 Feb 2004 01:29:19 +0800
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?
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?
Some pseudo-code for the secondary thread may be in order:
set up kqueue
do
{
wait for kevent; // this blocks until an kqueue event happens
if kevent == file change
perform some selector on main thread on some object
}
while (kevent != abort);
What would be a suitable abort event?
Cheers, Glen Low
---
pixelglow software | simply brilliant stuff
www.pixelglow.com
_______________________________________________
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.