On Nov 11, 2010, at 4:48 PM, jonat...@mugginsoft.com wrote: >> In case you would like to do similar things when using NSOperation and >> NSOperationQueue you might consider to send the message to the run loop >> instead, e.g.: -performSelector:target:argument:order:modes: >> >> Of course you would need a mechanism to get the corresponding run loop for >> that operation. I would suggest to define a property in your custom >> operation and set it when the operation enters its main method.
Unfortunately, after more carefully reading the docs, the method -performSelector:target:argument:order:modes: seems not appropriate for this tasks since it "schedules the sending of a message on the *current* run loop" - which is certainly not what you want :( It seems, the receiver of this message is irrelevant, hence the confusion. But there is still the possibility to ask for the current thread in -main and retain it in the custom operation. You may provide it readonly via a property. Likewise, you could then use -performSelector:onThread:withObject:waitUntilDone* or you could use custom methods for your operation which invoke performSelector:onThread itself. Access to the thread ivar should be synchronized. Be carefully though, the operation may not execute anymore or did not yet start when you try to schedule a selector on its thread. Note also, that many operations may be executed on the same thread. >> > That's a great idea that never occurred to me. I ended up not using > NSOperation recently because I could not figure out how to schedule a method. > Will definitely use this. _______________________________________________ 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
