• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag
 

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Objective-C in a Time Constraint Thread
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Objective-C in a Time Constraint Thread


  • Subject: Re: Objective-C in a Time Constraint Thread
  • From: Greg Parker <email@hidden>
  • Date: Tue, 28 Feb 2006 15:30:42 -0800

Chandrasekhar Ramakrishnan wrote:
I'm trying to get a better understanding of issues that may arise when using Objective-C inside of a CoreAudio IOProc.

The CoreAudio Hardware Abstraction Layer calls clients to produce audio on a time-constraint thread. Thus, audio generating functions are discouraged from invoking functions that may block the thread or take "a long time" to return (e.g., locking mutexes, allocating memory, reading from disk) [1].

Is this comment still accurate? If so, calling objc_msgSend in an IOProc is certainly risking audio glitches. Are there ways to decrease the probability of having the cache collected or is there any way to avoid it altogether? For example, will caching the IMP and invoking that directly help?

objc_msgSend() has two code paths: one where the selector is already in the receiver's class's method cache, and one where it is not.


The cached case is fast and audio-thread friendly.

The uncached case is not audio-thread friendly. This case will always add to the cache, which always locks a mutex. In some cases, it needs to allocate memory, which locks malloc's mutex. Occasionally, it will free the set of dead method caches, which involves more mutexes and some kernel calls. In practice, method cache cleanup occurs several times during launch and when a library or bundle is loaded. Cache cleanup rarely happens at other times.

You can reduce the chance of the uncached case by pre-heating the method cache. One way to do this is to use [NSObject respondsToSelector:] for the classes and selectors you want to use in the audio thread. (You don't care about the result of respondsToSelector: ; you just want the side-effect of adding that selector to that class's method cache.)

IMP caching bypasses objc_msgSend(), so it can't hit the uncached objc_msgSend() case. All caveats of IMP caching apply. Of course, if the method you're calling calls objc_msgSend() itself, you haven't saved much.


-- Greg Parker email@hidden Runtime Wrangler


_______________________________________________ Do not post admin requests to the list. They will be ignored. Cocoa-dev mailing list (email@hidden) Help/Unsubscribe/Update your Subscription: This email sent to email@hidden
  • Prev by Date: Re: Problems with NSGraphicsContext
  • Next by Date: Re: NSCalendar bug with adding to pre-1919 dates?
  • Previous by thread: Re: Objective-C in a Time Constraint Thread
  • Next by thread: Changing truncating mode for NSWindow Title
  • Index(es):
    • Date
    • Thread