• 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: Carbon is C++?
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Carbon is C++?


  • Subject: Re: Carbon is C++?
  • From: Ken Ferry <email@hidden>
  • Date: Mon, 19 Apr 2010 00:23:14 -0700

On Mon, Mar 1, 2010 at 4:03 AM, Greg Parker <email@hidden> 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     email@hidden     Runtime Wrangler
>
>
> _______________________________________________
>
> Cocoa-dev mailing list (email@hidden)
>
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
>
> Help/Unsubscribe/Update your Subscription:
>
> This email sent to email@hidden
>
_______________________________________________

Cocoa-dev mailing list (email@hidden)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:

This email sent to email@hidden

  • Prev by Date: Re: Warning with an initializer method of AMWorkflow
  • Next by Date: Re: Introspecting the current method
  • Previous by thread: Re: Blend mode 'darken' for NSImage?
  • Next by thread: blocks and autorelease weirdness
  • Index(es):
    • Date
    • Thread