Re: Stuck notes in Rax and Synthtest
Re: Stuck notes in Rax and Synthtest
- Subject: Re: Stuck notes in Rax and Synthtest
- From: Chris Reed <email@hidden>
- Date: Wed, 7 May 2003 20:43:24 -0500
I was under the impression that the general advice around here was to
use Mach semaphores directly. Some list members have done some serious
research into which API is the best to use for realtime audio purposes,
and the results were that Mach semaphores (and ports) were the only
ones that would not block... which is absolutely important for realtime
threading.
For example, using semaphores for inter-thread messaging. If you have
an ioproc running that needs to tell a feeder thread that its time to
produce more data, that ioproc might want to wake up the feeder thread
by signalling a semaphore. You don't want that call to block your
ioproc. If it's running at a realtime priority, no other thread will
get time until its done, so blocking causes all sorts of issues.
Mach ports are another part of the Mach API that are particularly
useful for signalling between thread without blocking. Create a
CFMachPortRef and add the run loop source to your favourite run loop.
Then you can send a trivial message to that Mach port to wake up the
run loop source and cause your callback to be executed on the run
loop's thread.
All of these things require access to the Mach thread. Probably the
reasoning behind TN2028 is that parts of the Mach API are still
unstable or not completely implemented, apparently.
-chris
On Wednesday, May 7, 2003, at 16:46 US/Central, Art Gillespie wrote:
From TN2028
"User-space processes should not create Mach threads directly."
And...
"In general, it is not appropriate to make Mach thread calls on
pthreads. Some exceptions are the Mach APIs for getting thread
information, setting up thread exception handlers, and death
notification, which should work for any Mach thread regardless of how
it was created."
So, as a plug-in, it's fair to assume that the host isn't using Mach
threads directly, or at least that they shouldn't be... given this and
the fact that you shouldn't make Mach thread API calls from
higher-level API threads (pthread, NSThread, etc.), I assumed this was
a bad idea.
Best,
Art
>>0xBA
On Wednesday, May 7, 2003, at 02:56 PM, Chris Reed wrote:
Except that you probably want to be using the Mach semaphores
(mach_semahore_t) instead pthread mutexes (which are built on the
Mach primitive), since the Mach sems feature nonblocking signaling.
-chris
_______________________________________________
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.