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:
http://lists.apple.com/mailman/options/cocoa-dev/email@hidden
