• 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: choice of thread API for audio feeder purposes
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: choice of thread API for audio feeder purposes


  • Subject: Re: choice of thread API for audio feeder purposes
  • From: Andrew Kimpton <email@hidden>
  • Date: Wed, 26 Mar 2003 20:18:49 -0800

Put simply (and this is a bit of an oversimplification) all the different thread models in Mac OS X are layered atop Mach thread primitives, some on top of each other.

If you want a purely carbon approach and need to run as a CFM app on OS 9 then MPTasks is probably the only way to go. It's also a relatively simple API at first glance however I've had problems 'dealing' with setting priorities on MPTasks and you'll probably end up looking at samples or documentation that refers to either mach or pthread calls which whilst you can in theory make by coercing/converting an MPTask to it's lower primitives can get confusing quickly.

If you're just working with OS X (or you're also working on some other Unix OS) then I'd recommend pthreads, again pthreads are implemented using Mach threads however the API is well documented (man pages and a book from O'Reilly). I'd also recommend reviewing Bill Stewarts presentation during WWDC 2002 where he talks about thread priorities, and also the Million Monkey's sample code. Listening to Bill's presentation and playing Million Monkeys can be very enlightening. Most of the priority setting code samples do use mach thread API calls to set priorities and they do this by converting/coercing a pthread ID into the mach thread type.

I'd recommend staying away from the 'raw' mach threads API IMHO the documentation can be confusing since mach threads are also used within the kernel and there tend to be a lot of kernel internal references and the like - pthreads will give you what you need.

Finally you can always wrap the 5-6 calls you need up in some C++ thread object (NSThread is just such an object for Obj-C) that way you can develop a relatively agnostic interface for the rest of your code and get it to work with whatever mechanism you like and it'll give you a cross-platform starting point. This is what I do in my code (mac, windows) and even survived the transition from MPTask to pthread without any real harm.

Andrew 8-)

P.S. A final reminder - review Million Monkeys and Bills presentation together - they're very helpful.
_______________________________________________
coreaudio-api mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/coreaudio-api
Do not post admin requests to the list. They will be ignored.
  • Follow-Ups:
    • Re: choice of thread API for audio feeder purposes
      • From: Kurt Bigler <email@hidden>
    • Re: choice of thread API for audio feeder purposes
      • From: Christof Faller <email@hidden>
References: 
 >choice of thread API for audio feeder purposes (From: Kurt Bigler <email@hidden>)

  • Prev by Date: choice of thread API for audio feeder purposes
  • Next by Date: Re: coreaudio java 1.4.1 issues? (Damien Everett)
  • Previous by thread: choice of thread API for audio feeder purposes
  • Next by thread: Re: choice of thread API for audio feeder purposes
  • Index(es):
    • Date
    • Thread