Carbon is C++?

  • is Apple's Carbon basically code written in C++, while Cocoa is
    written in Objective-C?  should developers avoid using frameworks
    written in C++ (like some sound frameworks)?
  • On Feb 25, 2010, at 3:40 PM, Chunk 1978 wrote:

    > is Apple's Carbon basically code written in C++, while Cocoa is
    > written in Objective-C?  should developers avoid using frameworks
    > written in C++ (like some sound frameworks)?

    Why? Objective-C and C++ mix just fine as long as you follow a few basic rules. Apple's documentation can tell you specifically what rules to follow.

    --
    Dave Carrigan
    <dave...>
    Seattle, WA, USA
  • i've been reading about how apple dropped their plans for Carbon 64 a
    while back, so if carbon is C++ then i'm surprised that apple is still
    supporting it at all?

    On Thu, Feb 25, 2010 at 6:42 PM, Dave Carrigan <dave...> wrote:
    >
    > On Feb 25, 2010, at 3:40 PM, Chunk 1978 wrote:
    >
    >> is Apple's Carbon basically code written in C++, while Cocoa is
    >> written in Objective-C?  should developers avoid using frameworks
    >> written in C++ (like some sound frameworks)?
    >
    >
    > Why? Objective-C and C++ mix just fine as long as you follow a few basic rules. Apple's documentation can tell you specifically what rules to follow.
    >
    > --
    > Dave Carrigan
    > <dave...>
    > Seattle, WA, USA
    >
    >
  • http://developer.apple.com/carbon/

    http://en.wikipedia.org/wiki/Carbon_%28API%29

    On Thu, Feb 25, 2010 at 15:40, Chunk 1978 <chunk1978...> wrote:

    > is Apple's Carbon basically code written in C++, while Cocoa is
    > written in Objective-C?  should developers avoid using frameworks
    > written in C++ (like some sound frameworks)?
    >
  • On 26/02/2010, at 10:40 AM, Chunk 1978 wrote:

    > is Apple's Carbon basically code written in C++, while Cocoa is
    > written in Objective-C?

    Some parts of Carbon is C++ internally, some is C, but the APIs are C.

    > should developers avoid using frameworks
    > written in C++ (like some sound frameworks)?

    No, C++ is supported and works fine. It's slightly more efficient than Obj-C so for time critical code like audio it's probably a better bet.

    --Graham
  • On Thu, Feb 25, 2010 at 6:42 PM, Dave Carrigan <dave...> wrote:
    >
    > On Feb 25, 2010, at 3:40 PM, Chunk 1978 wrote:
    >
    >> is Apple's Carbon basically code written in C++, while Cocoa is
    >> written in Objective-C?  should developers avoid using frameworks
    >> written in C++ (like some sound frameworks)?
    >
    >
    > Why? Objective-C and C++ mix just fine as long as you follow a few basic rules. Apple's documentation can tell you specifically what rules to follow.

    ... and what APIs are deprecated.

    sherm--

    --
    Cocoa programming in Perl:
    http://www.camelbones.org
  • On Feb 25, 2010, at 4:45 PM, Chunk 1978 wrote:

    > i've been reading about how apple dropped their plans for Carbon 64 a
    > while back,

    We just had a thread about this, but basically, Carbon is not dead; only parts of it were taken out of the 64-bit frameworks.

    > so if carbon is C++ then i'm surprised that apple is still
    > supporting it at all?

    First, Carbon might be internally implemented as C++, I don't know, but all of its exterior interfaces are in procedural C.

    Second, C++ is a fine language, and is not going to be deprecated any time soon, since a lot of stuff in the OS is written in C++ or ObjC++, such as the Security and WebKit frameworks. The only problem with C++ is the ABI keeps getting broken between compilers, so you might not be able to target really old versions of the OS with newer compilers.

    Nick Zitzmann
    <http://www.chronosnet.com/>
  • On Thu, Feb 25, 2010 at 5:45 PM, Chunk 1978 <chunk1978...> wrote:
    > i've been reading about how apple dropped their plans for Carbon 64 a
    > while back, so if carbon is C++ then i'm surprised that apple is still
    > supporting it at all?

    You're confusing a library/framework with the language that library is
    written in. Cocoa, Carbon, AppKit, Foundation, CoreServices,
    CoreFoundation, CoreGraphics, IOKit, etc... these are
    libraries/frameworks.

    Objective-C, Objective-C++, C, C++... these are languages.

    Some of the libraries I listed are pure C or C++, some Objective-C,
    and most are a mixture of all the languages.

    Apple has deprecated libraries/frameworks. They haven't stopped
    supporting any languages though. It's 100% safe to keep writing apps
    that use C++ if you are also using Cocoa. A large part of OS X itself
    is C++ (see: IOKit and Directory Services).
  • On Thu, Feb 25, 2010 at 7:02 PM, Stephen J. Butler
    <stephen.butler...> wrote:
    >
    > Apple has deprecated libraries/frameworks. They haven't stopped
    > supporting any languages though.

    I'm pretty sure they no longer support Pascal. ;-)

    sherm--

    --
    Cocoa programming in Perl:
    http://www.camelbones.org
  • On Feb 25, 2010, at 4:02 PM, Stephen J. Butler wrote:
    > Apple has deprecated libraries/frameworks. They haven't stopped
    > supporting any languages though.

    Pretty sure we don't provide any Pascal or HyperCard tools anymore. I forget whether we shipped gfortran at any point in Mac OS X.

    In any case, the llvm/clang team is hard at work on a new C++ compiler. Feel free to draw your own conclusions about Apple's future support for C++.

    http://blog.llvm.org/2009/12/clang-builds-llvm.html
    http://blog.llvm.org/2010/02/clang-successfully-self-hosts.html

    --
    Greg Parker    <gparker...>    Runtime Wrangler
  • On Feb 25, 2010, at 4:08 PM, Greg Parker wrote:

    > Feel free to draw your own conclusions about Apple's future support for C++.

    What Greg said. Note that a lot of major big-ticket Mac apps contain large amounts of C++ code — Photoshop, MS Office, etc. Most cross-platform apps are C++ at their core, even if they have a Cocoa UI layer. That includes even some Apple apps like Safari and iTunes.

    —Jens
  • On 2/25/10 4:54 PM, Nick Zitzmann said:

    > Second, C++ is a fine language, and is not going to be deprecated any
    > time soon, since a lot of stuff in the OS is written in C++ or ObjC++,
    > such as the Security and WebKit frameworks. The only problem with C++ is
    > the ABI keeps getting broken between compilers, so you might not be able
    > to target really old versions of the OS with newer compilers.

    Not sure that's the _only_ problem with C++. :)  But I won't start a
    language war. :)

    On OS X, there are some downsides to choosing C++: one is that the tools
    support is not as good.  Xcode's refactoring does not support C++, the
    debugger doesn't play nice with STL containers, the STL Debug mode is
    broken on 10.6, etc., etc.  C++ support is good, but it's not great.

    --
    ____________________________________________________________
    Sean McBride, B. Eng                <sean...>
    Rogue Research                        www.rogue-research.com
    Mac Software Developer              Montréal, Québec, Canada
  • Carbon was originally Pascal based, at least as far as the APIs. It does not essentially matter what it is written in, just what APIs it supports. If it has been rewritten in C++ (are they mad?), that should make no difference to whatever developer language is used, and would not be an argument to write in C++.

    Should you write any high-level applications in C++ - probably not. If you are just writing Cocoa apps - don't use it. Just stick to Objective-C.

    The idea of Objective-C++ is really to port things from other platforms more easily, or perhaps do cross-platform development.

    Ian

    On 26 Feb 2010, at 10:40, Chunk 1978 wrote:

    > is Apple's Carbon basically code written in C++, while Cocoa is
    > written in Objective-C?  should developers avoid using frameworks
    > written in C++ (like some sound frameworks)?
  • On Feb 28, 2010, at 1:20 AM, Ian Joyner wrote:

    > Carbon was originally Pascal based, at least as far as the APIs. It does not essentially matter what it is written in, just what APIs it supports. If it has been rewritten in C++ (are they mad?), that should make no difference to whatever developer language is used, and would not be an argument to write in C++.
    >
    > Should you write any high-level applications in C++ - probably not. If you are just writing Cocoa apps - don't use it. Just stick to Objective-C.
    >
    > The idea of Objective-C++ is really to port things from other platforms more easily, or perhaps do cross-platform development.

    Or if you want to do a bunch of audio stuff in the iPhone, then you can enjoy the experience of learning C++ even though all you want to do is obj-c. Depressing.
  • On Sun, Feb 28, 2010 at 1:33 PM, Paul Bruneau
    <paul_bruneau...> wrote:
    > Or if you want to do a bunch of audio stuff in the iPhone, then you can enjoy the experience of learning C++ even though all you want to do is obj-c. Depressing.

    Nothing in Core Audio requires you to use C++, but all of the stuff in
    PublicUtility is C++. You could implement an audio unit in straight C
    if you wanted.

    ObjC would never be a good idea for audio because it involves far too
    much latency. Audio demands realtime performance, which a dynamic
    language like ObjC simply cannot give you.

    --Kyle Sluder
  • I disagree.  I have written very low latency device drivers in Objective-C.  Why do you think Objective-C has too much "latency" for audio?  When properly used, Objective-C programs are no more likely to be preempted than any other kind of program.  Message dispatch generally has constant time and is only 2.5 times the cost of a C function call.  There aren't many function calls or messages sent in audio processing anyway.  Signal processing routines tend to be long loops.  Objective-C _IS_ C which means it is likely usable in any situation where C is usable.

    On Feb 28, 2010, at 8:23 PM, Kyle Sluder wrote:

    > On Sun, Feb 28, 2010 at 1:33 PM, Paul Bruneau
    > <paul_bruneau...> wrote:
    >> Or if you want to do a bunch of audio stuff in the iPhone, then you can enjoy the experience of learning C++ even though all you want to do is obj-c. Depressing.
    >
    > Nothing in Core Audio requires you to use C++, but all of the stuff in
    > PublicUtility is C++. You could implement an audio unit in straight C
    > if you wanted.
    >
    > ObjC would never be a good idea for audio because it involves far too
    > much latency. Audio demands realtime performance, which a dynamic
    > language like ObjC simply cannot give you.
    >
    > --Kyle Sluder
  • That is excellent and I really like the sound of it. Someone please inform the authors of Apple's iPhone sample code so that I won't have to deal with C++ anymore! (I'm looking at YOU, SpeakHere!)

    On Feb 28, 2010, at 10:24 PM, Erik Buck wrote:

    > I disagree.  I have written very low latency device drivers in Objective-C.  Why do you think Objective-C has too much "latency" for audio?  When properly used, Objective-C programs are no more likely to be preempted than any other kind of program.  Message dispatch generally has constant time and is only 2.5 times the cost of a C function call.  There aren't many function calls or messages sent in audio processing anyway.  Signal processing routines tend to be long loops.  Objective-C _IS_ C which means it is likely usable in any situation where C is usable.
  • On Sun, Feb 28, 2010 at 7:24 PM, Erik Buck <erik.buck...> wrote:
    > I disagree.  I have written very low latency device drivers in Objective-C.  Why do you think Objective-C has too much "latency" for audio?  When properly used, Objective-C programs are no more likely to be preempted than any other kind of program.  Message dispatch generally has constant time and is only 2.5 times the cost of a C function call.  There aren't many function calls or messages sent in audio processing anyway.  Signal processing routines tend to be long loops.  Objective-C _IS_ C which means it is likely usable in any situation where C is usable.

    I am simply relaying the wisdom I received from the CoreAudio folks
    over on coreaudio-api. Frequently people ask about using ObjC in their
    render callbacks, and the engineers are quick to put the kibosh on
    that idea.

    --Kyle Sluder
  • On Feb 28, 2010, at 7:24 PM, Erik Buck wrote:

    > I disagree.  I have written very low latency device drivers in Objective-C.  Why do you think Objective-C has too much "latency" for audio?  When properly used, Objective-C programs are no more likely to be preempted than any other kind of program.  Message dispatch generally has constant time and is only 2.5 times the cost of a C function call.

    That just cannot be true. But if you need speed you can write a direct C style subroutine and call, and it will be swift. The dynamic binding of ObC messages often isn't needed.

    > There aren't many function calls or messages sent in audio processing anyway.  Signal processing routines tend to be long loops.  Objective-C _IS_ C which means it is likely usable in any situation where C is usable.
    >
    >
  • On Feb 28, 2010, at 7:35 PM, Paul Bruneau wrote:

    > That is excellent and I really like the sound of it. Someone please inform the authors of Apple's iPhone sample code so that I won't have to deal with C++ anymore! (I'm looking at YOU, SpeakHere!)

    SpeakHere displays one of the things I like very much about C++,  the special status of constructors and destructors. You must have them. If they do nothing there is no extra cost. If a base class requires initialization, the compiler will insist you provide it. No forgetting [super init] and the like.
  • On Feb 28, 2010, at 10:49 PM, David Rowland wrote:

    >
    > On Feb 28, 2010, at 7:24 PM, Erik Buck wrote:
    >
    >> I disagree.  I have written very low latency device drivers in Objective-C.  Why do you think Objective-C has too much "latency" for audio?  When properly used, Objective-C programs are no more likely to be preempted than any other kind of program.  Message dispatch generally has constant time and is only 2.5 times the cost of a C function call.
    >
    > That just cannot be true. But if you need speed you can write a direct C style subroutine and call, and it will be swift. The dynamic binding of ObC messages often isn't needed.

    http://www.mikeash.com/pyblog/performance-comparisons-of-common-operations-
    leopard-edition.html

    http://www.friday.com/bbum/2009/12/18/objc_msgsend-part-1-the-road-map/
    http://ridiculousfish.com/blog/archives/2005/08/01/objc_msgsend/
    http://www.mulle-kybernetik.com/artikel/Optimization/

    See gcc option -fobjc-direct-dispatch

    Interesting research: http://www.jot.fm/issues/issue_2009_01/article4/

    >
    >
    >> There aren't many function calls or messages sent in audio processing anyway.  Signal processing routines tend to be long loops.  Objective-C _IS_ C which means it is likely usable in any situation where C is usable.
    >>
    >>
    >
  • All my audio render callbacks use the C-function-pointer-to-call-named-selector trick in JambaLaya. (http://audiofreakshow.com)

    In fact, the entire app is written in Objective-C.  Between SnoizeMIDI, MTCoreAudio, and my own private TBAudioUnits framework - I deal with C or C++ almost never.

    In fact, SnoizeMIDI (http://snoize.com/) is a great example of something that most people would think would be too slow. It takes the high performance data structures like MIDIMessageList variable length structs, then converts them into NSArray's of Objective-C objects (one per message), then dispatches them through a chain of Objective-C implemented filters using polymorphism. I end up stashing them in a set of NSArray implemented queues (protected by NSLock) from which they are pulled during that "probably too slow" Objective-C implemented render callback -then dispatched to the audio units, and then released.

    Very low latency, feels like hardware, and all Objective-C.

    There is no good reason not to have the base classes for AudioUnit be in Objective-C rather than C++ other than the personal biases of certain CoreAudio team members.  I can't fault them, they use what they know and they do a great job, but their way isn't the only one and a nice Objective C wrapper for the whole thing that hides the C++ is both doable and a long standing feature request.

    On Feb 28, 2010, at 7:46 PM, Kyle Sluder wrote:

    > On Sun, Feb 28, 2010 at 7:24 PM, Erik Buck <erik.buck...> wrote:
    >> I disagree.  I have written very low latency device drivers in Objective-C.  Why do you think Objective-C has too much "latency" for audio?  When properly used, Objective-C programs are no more likely to be preempted than any other kind of program.  Message dispatch generally has constant time and is only 2.5 times the cost of a C function call.  There aren't many function calls or messages sent in audio processing anyway.  Signal processing routines tend to be long loops.  Objective-C _IS_ C which means it is likely usable in any situation where C is usable.
    >
    > I am simply relaying the wisdom I received from the CoreAudio folks
    > over on coreaudio-api. Frequently people ask about using ObjC in their
    > render callbacks, and the engineers are quick to put the kibosh on
    > that idea.
    >
    > --Kyle Sluder
  • Le 1 mars 2010 à 05:55, Erik Buck a écrit :

    >
    > On Feb 28, 2010, at 10:49 PM, David Rowland wrote:
    >
    >>
    >> On Feb 28, 2010, at 7:24 PM, Erik Buck wrote:
    >>
    >>> I disagree.  I have written very low latency device drivers in Objective-C.  Why do you think Objective-C has too much "latency" for audio?  When properly used, Objective-C programs are no more likely to be preempted than any other kind of program.  Message dispatch generally has constant time and is only 2.5 times the cost of a C function call.
    >>
    >> That just cannot be true. But if you need speed you can write a direct C style subroutine and call, and it will be swift. The dynamic binding of ObC messages often isn't needed.
    >
    > http://www.mikeash.com/pyblog/performance-comparisons-of-common-operations-
    leopard-edition.html

    > http://www.friday.com/bbum/2009/12/18/objc_msgsend-part-1-the-road-map/
    > http://ridiculousfish.com/blog/archives/2005/08/01/objc_msgsend/
    > http://www.mulle-kybernetik.com/artikel/Optimization/
    >
    > See gcc option -fobjc-direct-dispatch
    >

    This option is a noop on Intel arch.
    And it does not prevent the main issue when dealing with objc_msgSend. The dispatch time is not constant.
    The runtime may have to use slow dispatch path when the method is not cached (and even have to use malloc to increase cache size).

    > Interesting research: http://www.jot.fm/issues/issue_2009_01/article4/
    >
    >>
    >>
    >>> There aren't many function calls or messages sent in audio processing anyway.  Signal processing routines tend to be long loops.  Objective-C _IS_ C which means it is likely usable in any situation where C is usable.
    >>>
    >>>
    >>
    >

    -- Jean-Daniel
  • On Feb 28, 2010, at 7:24 PM, Erik Buck wrote:
    > I disagree.  I have written very low latency device drivers in Objective-C.  Why do you think Objective-C has too much "latency" for audio?  When properly used, Objective-C programs are no more likely to be preempted than any other kind of program.  Message dispatch generally has constant time and is only 2.5 times the cost of a C function call.  There aren't many function calls or messages sent in audio processing anyway.  Signal processing routines tend to be long loops.  Objective-C _IS_ C which means it is likely usable in any situation where C is usable.

    Message dispatch is generally fast. For many real-time-ish purposes that's good enough. But occasionally message dispatch (1) takes much longer, and (2) acquires locks. For some real-time-ish purposes, this sort of surprise is fatal when it occurs. Since there's no way for the program to control when dispatch is fast and when it is slow, clients with sufficiently tight "no surprises" requirements should avoid it altogether. If your requirements are demanding enough that you can't call malloc(), then you probably can't call objc_msgSend() either.

    It's the locks that kill. With care, a real-time-ish thread can pretty much solve problems of page faults and scheduling and the like. But the moment you take a lock, you're at the mercy of some other thread that may not be so careful.

    Audio clients tend to be the most paranoid about this on Mac OS X. They're the closest to truly-real-time requirements that I see, with good reason: if your audio playback skips, ever, you probably just lost a customer.

    --
    Greg Parker    <gparker...>    Runtime Wrangler
  • On 26.02.2010, at 15:12, Sean McBride wrote:
    > the STL Debug mode is broken on 10.6, etc., etc.  C++ support is good, but it's not great.

    I guess this is off-topic for this list, but could you maybe give a short link or so regarding what "the STL debug mode" would be, and how it is broken? I'm using lots of C++, and this would be helpful.

    Cheers,
    -- Uli Kusterer
    "The witnesses of TeachText are everywhere..."
  • Hi,
    everyone say: "ObjC is slower then C++", but I/O Kit in the NextStep was
    written in ObjC, I really don`t think Next`s engineers didn`t know that. Now
    many crazy people write games in C# (managed language), but says that ObjC
    is not appropriate because it dynamically. Your experience is greater then
    mine, what do you think?

    2010/3/1 Greg Parker <gparker...>

    > On Feb 28, 2010, at 7:24 PM, Erik Buck wrote:
    >> I disagree.  I have written very low latency device drivers in
    > Objective-C.  Why do you think Objective-C has too much "latency" for audio?
    > When properly used, Objective-C programs are no more likely to be preempted
    > than any other kind of program.  Message dispatch generally has constant
    > time and is only 2.5 times the cost of a C function call.  There aren't many
    > function calls or messages sent in audio processing anyway.  Signal
    > processing routines tend to be long loops.  Objective-C _IS_ C which means
    > it is likely usable in any situation where C is usable.
    >
    > Message dispatch is generally fast. For many real-time-ish purposes that's
    > good enough. But occasionally message dispatch (1) takes much longer, and
    > (2) acquires locks. For some real-time-ish purposes, this sort of surprise
    > is fatal when it occurs. Since there's no way for the program to control
    > when dispatch is fast and when it is slow, clients with sufficiently tight
    > "no surprises" requirements should avoid it altogether. If your requirements
    > are demanding enough that you can't call malloc(), then you probably can't
    > call objc_msgSend() either.
    >
    > It's the locks that kill. With care, a real-time-ish thread can pretty much
    > solve problems of page faults and scheduling and the like. But the moment
    > you take a lock, you're at the mercy of some other thread that may not be so
    > careful.
    >
    > Audio clients tend to be the most paranoid about this on Mac OS X. They're
    > the closest to truly-real-time requirements that I see, with good reason: if
    > your audio playback skips, ever, you probably just lost a customer.
    >
    >
    > --
    > Greg Parker    <gparker...>    Runtime Wrangler
    >
  • On Feb 28, 2010, at 11:39 PM, Eagle Offshore wrote:

    > There is no good reason not to have the base classes for AudioUnit be in Objective-C rather than C++ other than the personal biases of certain CoreAudio team members.

    That's kind of insulting to those team members. The real reason is that most of the existing audio apps that needed to adopt these APIs were (are?) written in Carbon, not Cocoa. There was no way that Apple was going to tell developers like Bias, EMagic, Ableton and Propellerheads back in 2000 that they had to rewrite their apps — or even just their audio engines — from scratch in "some weirdo language".

    Certainly nowadays (ten years later!) it would make more sense to have the media stuff in Objective-C. And I'm sure Apple's aware of that. They've chosen to start with QuickTime, and over the last few OS releases have modernized large swathes of it. Hopefully they'll work on the CoreAudio APIs next.

    IMHO the worst problem with CoreAudio isn't what language it's in, but that the APIs don't form a coherent framework, rather a patchwork of complex procedural interfaces plus a pile of undocumented, mostly-unsupported and poorly-structured wrapper classes. Languages aren't a big deal — you should already be trying to learn a new language every year just to keep your mind flexible :)

    —Jens
  • On Mar 1, 2010, at 12:22 PM, Jens Alfke wrote:

    > IMHO the worst problem with CoreAudio isn't what language it's in,
    > but that the APIs don't form a coherent framework, rather a
    > patchwork of complex procedural interfaces plus a pile of
    > undocumented, mostly-unsupported and poorly-structured wrapper
    > classes. Languages aren't a big deal — you should already be trying
    > to learn a new language every year just to keep your mind flexible :)

    This actually makes me feel a lot better about my total inability to
    do anything at all in CoreAudio without relying almost completely upon
    the sample code. Thank you.
  • On Mon, Mar 1, 2010 at 9:22 AM, Jens Alfke <jens...> wrote:
    > IMHO the worst problem with CoreAudio isn't what language it's in, but that the APIs don't form a coherent framework, rather a patchwork of complex procedural interfaces plus a pile of undocumented, mostly-unsupported and poorly-structured wrapper classes. Languages aren't a big deal — you should already be trying to learn a new language every year just to keep your mind flexible :)

    Very much seconded. Thank goodness the engineers are so active and
    helpful on coreaudio-api. Otherwise I think it would be impossible to
    use PublicUtility successfully.

    --Kyle Sluder
  • On Mon, Mar 1, 2010 at 4:03 AM, Greg Parker <gparker...> wrote:

    > On Feb 28, 2010, at 7:24 PM, Erik Buck wrote:
    >> I disagree.  I have written very low latency device drivers in
    > Objective-C.  Why do you think Objective-C has too much "latency" for audio?
    > When properly used, Objective-C programs are no more likely to be preempted
    > than any other kind of program.  Message dispatch generally has constant
    > time and is only 2.5 times the cost of a C function call.  There aren't many
    > function calls or messages sent in audio processing anyway.  Signal
    > processing routines tend to be long loops.  Objective-C _IS_ C which means
    > it is likely usable in any situation where C is usable.
    >
    > Message dispatch is generally fast. For many real-time-ish purposes that's
    > good enough. But occasionally message dispatch (1) takes much longer, and
    > (2) acquires locks. For some real-time-ish purposes, this sort of surprise
    > is fatal when it occurs. Since there's no way for the program to control
    > when dispatch is fast and when it is slow, clients with sufficiently tight
    > "no surprises" requirements should avoid it altogether. If your requirements
    > are demanding enough that you can't call malloc(), then you probably can't
    > call objc_msgSend() either.
    >
    > It's the locks that kill. With care, a real-time-ish thread can pretty much
    > solve problems of page faults and scheduling and the like. But the moment
    > you take a lock, you're at the mercy of some other thread that may not be so
    > careful.
    >
    > Audio clients tend to be the most paranoid about this on Mac OS X. They're
    > the closest to truly-real-time requirements that I see, with good reason: if
    > your audio playback skips, ever, you probably just lost a customer.
    >

    Just for those who haven't already noticed this interesting detail, audio is
    more constrained than video.  If your movie skips a frame?  You probably
    cannot tell.  If your audio drops?  Urgh!

    -Ken

    >
    >
    > --
    > Greg Parker    <gparker...>    Runtime Wrangler
    >
previous month february 2010 next month
MTWTFSS
1 2 3 4 5 6 7
8 9 10 11 12 13 14
15 16 17 18 19 20 21
22 23 24 25 26 27 28
Go to today