Re: Questions on MIDINotifications and threads
Re: Questions on MIDINotifications and threads
- Subject: Re: Questions on MIDINotifications and threads
- From: Kurt Revis <email@hidden>
- Date: Mon, 18 Feb 2002 22:49:55 -0800
I said:
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.)
By the way, this also interferes with a very common Cocoa idiom. Often
we want to cause something to happen the next time through the app's
main event loop. This is done like this:
[myObject performSelector:@selector(doSomethingWithObject:)
withObject:foo afterDelay:0];
This method internally creates a one-shot timer and adds it to the run
loop, in the default mode. So the next time the run loop is run in the
default mode (which should be only the top-level event loop), the timer
fires and [myObject doSomethingWithObject:foo] is called.
But since CoreMIDI is also running the run loop in the default mode, now
that method call can happen inside of a CoreMIDI function, instead of
where we expect it to happen!
This is *really* a pain to deal with and is not easy to work around. The
only workaround I can come up with is to set a flag before calling any
CoreMIDI function, and clear it after that function returns. Then *any*
delayed method (even ones totally unrelated to CoreMIDI) must check the
flag -- if it's set, the method must call the
performSelctor:withObject:afterDelay: again so it can get another try
later on. Obviously, this is disgusting.
CoreMIDI folks, I beseech thee: please fix this. Thanks.
--
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.