2

Just found in Apple docs:

Note: 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.

Why is it so? How much is "frequent"?

I have an app with a lot of threads and a lot of stuff happening in main thread (heavy JavaScript, frequent Ajax queries in a WebKit). On Yosemite, I started to experience huge problems in combination of several (say, 10) file downloads (NSURLDownloads) plus the WebKit GUI (required to run in the main thread).

File downloads cannot "live" long with a WebKit heavily loaded by JavaScript. At some point, all network requests start returning timeout (error -1001) until the app quits.

And I widely use performSelector:onThread:withObject:waitUntilDone:, e.g. to notify UI about the download progress. This can happen many times per second. Can it be the problem?

P.S. Unfortunately, I'm not allowed to show the whole source code...

Dmitry Isaev
  • 3,888
  • 2
  • 37
  • 49

1 Answers1

0

Strangely, on the Yosemite documentation, there is no such warning in NSObject's documentation...

Though perhaps only Apple can give the real reason, I suspect it has to do with performance. Note this paragraph in the documentation for that call in NSObject:

This method queues the message on the run loop of the target thread using the default run loop modes—that is, the modes associated with the NSRunLoopCommonModes constant. As part of its normal run loop processing, the target thread dequeues the message (assuming it is running in one of the default run loop modes) and invokes the desired method.

In other words, when you're using the method, you're passing objects around on the different threads on the system, and there is probably some overhead in this process. The system only guarantees that it will be executed directly by the target thread - it does not say when it will be executed. If the target thread is already doing something, your method may not be called for some time. Therefore, it is better for sending messages to threads (I.e to update a flag or something) rather than having something run immediately because, like all things with threads, there is no guarantee of immediate execution.

To sum up, the warning is likely there for two reasons:

  • There is some overhead to doing this, and so it is not good for sending rapid messages
  • There is no guarantee when the method will be executed; it all depends on when the CPU scheduler gives the thread execution time and what the thread is doing when that happens
SevenBits
  • 2,836
  • 1
  • 20
  • 33
  • I can understand some delays, okay. But, as I said, network becomes completely unresponsive. So I thought, there might be another reason. Maybe a Yosemite-specific bug... – Dmitry Isaev Jan 04 '15 at 08:08