On Feb 26, 2006, at 5:19 AM, Chandrasekhar Ramakrishnan wrote:
On the CoreAudio list, it was pointed out that "... ObjC message
sends are treated as an opportunity for the ObjC runtime to re-
evaluate its world, and thus can not only involve locks, but also
memory allocations" [2].
I looked at the source for objc_msgSend <http://
darwinsource.opendarwin.org/10.3/objc4-235/runtime/
Messengers.subproj/objc-msg-ppc.s> and, sure enough, there is a
comment before the macro LockCache:
; The collecting cache mechanism precludes the need for a cache lock
; in objc_msgSend. The cost of the collecting cache is small: a few
; K of memory for uncollected caches, and less than 1 ms per
collection.
; A large app will only run collection a few times.
I'm assuming this is what was being referred to in the ca-api list
post.
This says that it doesn't need a lock for the cache so I'm not sure
that this is what they're talking about.
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?
Is which comment still accurate? Avoiding the overhead of the
objective-c call seems like a good idea to me. I'd be more concerned
with what the call itself does. If you're creating new objects then
you're allocating memory which should be avoided.
_______________________________________________
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
This email sent to email@hidden
