NSOperation.pdf states:
"For a non-concurrent operation, an operation queue automatically
creates a thread and calls the operation object’s start method, the
default implementation of which configures the thread environment and
calls the operation object’s main method to run your custom code."
In my app, I have a very long for-loop, each time thru which, I call
NSInvocationOperation's -initWithTarget:selector:object:, followed by
a call to add the resulting Operation to the NSOperationQueue. This
queue is previously created via itsQueue = [[NSOperationQueue alloc]
init], itsQueue being a instance variable.
I do not have a custom -start or a -main method, so I count on the
default -start and -main methods to handle the creation of a
background Thread for me. It appears however, that in my app there is
no background Thread that begins and the reason for that is because my
app's window stays in the background until all NSOperations are
complete. Any clues?
By the way, when I alternately use either +detachNewThreadSelector or
NSMachPorts, everything works just fine, including the app's window
coming to the foreground, which event I force via [NSApp
activateIgnoringOtherApps:YES] even before I start the background
Thread.
One last question .. if a new background Thread is automatically
started when I add the new NSInvocationOperation to the
NSOperationQueue, is there a NSAutoreleasePool automatically created
before the above selector method starts and is this NSAutoreleasePool
released after this method finishes?
John Love
Touch the Future! Teach!
_______________________________________________
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
