Re: Questions on MIDINotifications and threads
Re: Questions on MIDINotifications and threads
- Subject: Re: Questions on MIDINotifications and threads
- From: Doug Wyatt <email@hidden>
- Date: Tue, 19 Feb 2002 09:24:04 -0800
On Monday, February 18, 2002, at 10:22 , Kurt Revis wrote:
On Monday, February 18, 2002, at 09:36 PM, Pete Yandell wrote:
Am I correct in assuming that my MIDINotifyProc will get called from a
thread over than my applications main thread?
No, the notify proc is called in your app's main thread--the
notification comes in through its run loop. (I'm not sure exactly how
this is implemented--I would think CoreMIDI would set up a one-shot
timer to do this but I haven't looked at it lately.)
I think a backtrace would show you, the notification comes in as a Mach
message to a CFMessagePort.
What seems to be happening in my app at the moment is that a
notification arrives and then, half way through the method that
processes the notification, another notification arrives and
interrupts the first. (I presume this means that my MIDINotifyProc is
actually being run in two separate CoreMIDI threads simultaneously!)
Meanwhile my app is halfway through updating its data structures and
gets mighty confused. Is this expected behavior?
That's not actually what's happening. I bet you are calling CoreMIDI
from within your notification proc, and then your notification proc
gets called again in the middle of the CoreMIDI call. (Set a breakpoint
on your notification proc and check the backtrace.)
What is happening is that CoreMIDI internally uses the run loop to
communicate with the MIDIServer process. So calling, say,
MIDIGetNumberOfSources() causes a request to be sent to the MIDIServer,
and then the run loop is run. When the MIDIServer sends a response
back, it comes in through the run loop, and the CoreMIDI function
returns it to you.
The problem here is that CoreMIDI is running its internal run loop in
the default run loop mode (which is the same mode in which your app
does its top-level run loop processing). I really think this is a bug,
and that it should be running in its own private mode. (I've filed a
bug on this, #2852701.)
You're right, the client-side of the API implementation is sending a
Mach message to the server and waiting for a Mach message reply in the
calling runloop's default mode -- I do consider it a bug that other
runloop sources get a chance to fire during this wait, which is normally
extremely short, but apparently Cocoa uses the runloop in ways that
expose this bug --we've never seen it in our mostly-Carbon and command
tool-based test suite.
This will get fixed for the next CoreMIDI update.
Doug
--
Doug Wyatt
work: email@hidden (CoreAudio)
personal: email@hidden
http://www.sonosphere.com
"There is no way to peace. Peace is the way."
-- A.J. Muste
_______________________________________________
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.