On Jan 30, 2006, at 10:12 PM, William Stewart wrote:
No frustration - I'm trying to be clear and to understand the context of your comments. Good to know, thanks for the reassurance! We've discussed with a number of people the suitability of using ObjC for real-time (or better, time-constrained) implementations... It has made us nervous, given 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. I would be extremely concerned and extremely cautious about using ObjC in this manner; for a view it is excellent of course. I'm sure others would have a point of view about this...
While I'm not an expert about ObjC messaging, I don't think it's quite as much of a crap shoot as you suggest. As I understand it there is some lookup and binding that happens on the first call to an object's method, for instance, but afterward it is cached and behaves much like a normal subroutine call.
You might be right about the possibility of memory allocations on the first call, but is this much different than a C++ Audio Unit malloc'ing support objects with "new" ?
I tend to think of the ObjC as *relatively* high-level, consisting of essentially an advanced allocation and caching system - I don't imagine there being much locking in the straightforward use of the runtime to prepare and call through to object methods.
Would love to hear the opinions of others more experienced with both ObjC and CoreAudio, though.
Daniel
|