Re: Property notification questions
Re: Property notification questions
- Subject: Re: Property notification questions
- From: Kurt Revis <email@hidden>
- Date: Wed, 12 Feb 2003 14:19:23 -0800
On Wednesday, February 12, 2003, at 12:36 PM, Chris Reed wrote:
Like I said, this all works fine. But it seems too complicated.
It seems as though you could skip a step: go directly from the ioproc
thread to the main thread. Here's a rough outline:
1. At startup:
Create a CFMachPort and give it your callback function.
Get a run loop source from it
Install the source on the main thread's run loop
Set the Mach port to have a queue length of 1, using
mach_port_set_attributes(). (*)
2. When you want to post a notification in the ioproc thread:
Put it in your queue (must be nonblocking)
Send a trivial message to the Mach port (*).
If you use a timeout of 0, this should never block.
3. Your callback function will be called in the main thread.
It should remove all of the notifications from the queue and process
them.
You're in the main thread so you can draw if necessary.
(*) See the CoreFoundation source for an example of how to do this.
http://www.opensource.apple.com/projects/darwin/6.0/source/apsl/
CoreFoundation-262.tar.gz
Specifically, in CFRunLoop.c, search for mach_port_set_attributes() and
__CFSendTrivialMachMessage.
I think this will work, but I haven't actually tried it yet, so be
warned :)
The only other way I know to wake up another thread, without
potentially blocking, is to use a Mach semaphore. But the sleeping
thread needs to specifically wait on the semaphore, so that precludes
using a run loop in that thread. The above technique lets you wake up
the thread without blocking *and* still use a run loop.
Also note that creating a simple type 0 CFRunLoopSource and using
CFRunLoopSourceSignal() from the ioproc thread is *almost* the same as
above. But unfortunately CFRunLoopSourceSignal() needs to take a lock
on the run loop source, which is unacceptable in our case. Too
bad--it's a whole lot easier.
Or we could even skip the whole notification thread thing and install
the run loop timer directly when the notification is triggered--but
that would probably be bad for a realtime thread.
Right, I'm sure you can't do this without potentially blocking (see the
CoreFoundation source).
--
Kurt Revis
email@hidden
_______________________________________________
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.