Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.
Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.
Lost your password? Please enter your email address. You will receive a link and will create a new password via email.
Please briefly explain why you feel this question should be reported.
Please briefly explain why you feel this answer should be reported.
Please briefly explain why you feel this user should be reported.
Apple’s Threading Programming Guide states that:
Although good for occasional
communication between threads, you
should not use the
performSelector:onThread:withObject:waitUntilDone:
method for time critical or frequent
communication between threads.
Which begs the questions: Which is, then, the acceptable method for frequent inter-thread communication, and why is performSelector:onThread:withObject:waitUntilDone: specifically not recommended.
ps: Not waiting until done, naturally.
The reason they don’t recommend using that probably is because this has a lot of overhead. Also it works only with threads that have a
NSRunlooprunning. It’s really good for updating the UI from a secondary thread though.For more heavy duty lifting you should use shared memory (with locks or lockless algorithms) for inter-thread-communication. Or even better use something like NSOperationQueue or Grand Central Dispatch and don’t worry about doing the communication and synchronization yourself, if your problem permits that.