Re: threading questions
Re: threading questions
- Subject: Re: threading questions
- From: Jeff Moore <email@hidden>
- Date: Mon, 17 Nov 2003 11:28:42 -0800
This isn't going to happen, at least not on the same device. It's hard
to do IO if the format of a stream changes on you until you know about
it. When the driver tells the HAL that something major has changed, the
HAL won't call any IOProcs again until it has completely finished
calling out to the listeners. Conversely, the HAL holds off handling
notifications from the driver until the IO thread has gone to sleep.
The HAL works very hard to only call out to IOProcs/listeners for a
given device when that device is in a consistent state.
That said, if you are dealing with multiple devices, the IOProc for
device A can certainly interrupt you while you are processing a
notification from device B. The converse is generally not true unless
you go CPU bound in an IOProc for an extended period of time such that
the thread priority has degraded far enough or you have configured
kAudioHardwarePropertyRunLoop to use a thread that can successfully
compete against a time constraint thread.
And as Doug says, on MP systems, you won't get interrupted at all, but
rather the two threads will run concurrently.
On Nov 15, 2003, at 3:08 PM, Matthew D Hancher wrote:
Doug Wyatt wrote:
I'd just add that on a dual CPU, the probability of multiple callbacks
into your code running simultaneously is much greater than on a
single-processor machine...
Yeah, this is the exactly the problem that has been keeping me up at
night these days. For instance, how on earth am I supposed to proceed
if an IOProc is called on one processor while I am processing a
notification that that device has been reconfigured on the other
processor?
I guess that example is still an issue on single-processor systems,
since the IOProc might reasonably interrupt the notification thread.
I'd be fine with locking the device in these rare circumstances, but I
can't even be sure that I'll get the chance to lock it before I'm
interrupted. In this case the device is expecting me to behave as
though I've received the notification, but as far as I'm concerned I
haven't.
What's the usual framework for safely handling notifications about
changes to a device while the device is in active use?
Thanks,
Matt
On Nov 10, 2003, at 12:33, Jeff Moore wrote:
Unless one were to configure kAudioHardwarePropertyRunLoop in a very
odd way, it isn't likely that another thread would interrupt your
IOProc to deliver notifications, but if you were to call back into
the
HAL to change some state of the device from inside your IOProc, there
is every likelihood that your listener procs will get called while
your IOProc is executing.
For that matter, can one IOProc interrupt another IOProc?
For most drivers, there is only one thread per device per process.
So,
multiple IOProcs on the same device will not interrupt each other.
But
if each IOProc is attached to a different device, then it is possible
for the threads to interrupt each other if your IOProc takes long
enough to execute.
--__--__--
Message: 5
Date: Sat, 15 Nov 2003 05:43:16 +0100
Subject: Re: Logic Audio and MAXFILEs
From: Cyril Blanc <email@hidden>
To: Markus Fritze <email@hidden>
Cc: liste Cure audio <email@hidden>, Marc Poirier
<email@hidden>
On 14/11/03 19:41, "Markus Fritze" <email@hidden> wrote:
Markus, if you have a minute can you answer to the following
questions
:
Ehm, this is the Core-Audio API forum. It is for developers and NOT a
support forum for Logic. Use <email@hidden>, LUG or other forums
for this. Thank you.
Markus
Hello Markus,
Thanks for your answer.
I will try support.
Best regards
Cyril Blanc
France
Please sign the petition 3Apple to support APPLE LaserWriter 300 in
MAC OS
X2
http://www.PetitionOnline.com/Ap1c1/petition.html
If you want to be sure I read your answer leave my name in it !
Spam mails are directly going to trash
--__--__--
_______________________________________________
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.
End of coreaudio-api Digest
_______________________________________________
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.
_______________________________________________
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.