Re: CoreMIDI problem
Re: CoreMIDI problem
- Subject: Re: CoreMIDI problem
- From: Doug Wyatt <email@hidden>
- Date: Mon, 22 May 2006 14:02:44 -0700
On May 22, 2006, at 13:38 , Stéphane LETZ wrote:
Le 22 mai 06 à 21:49, Doug Wyatt a écrit
The MIDISendSysex function's implementation is entirely on the
client side (not in the server ... well, actually there's a
duplicate implementation in the server, but that's only for
drivers). This implementation actually creates its own private
client and output port, which is why disposing your own port and
client have no effect.
But why not give a way to cleany close these "private client and
output port" ?
We could, though it would require Leopard ...
One strategy would be to set the MIDISysexSendRequest's complete
flag to true, to signify that you wish to abort. Then wait for
your completion function to be called (which will occur on a
separate thread owned by the implementation). At this point you
can be sure your completion function won't be called any more.
It may be simpler and more robust to maintain a global indicating
whether your completion function should do anything when it's called.
Well, this seems a bit ugly...
I get cases where the completion callback seems to not even by
called correctly: with something like "lazy_bind crash error"
trying to find symbols... (I don't remember the exact code...) as
if the callback was called when code was being unloaded..
It would be good to file a bug report including backtraces of all
threads. I can't think of a reason why what I suggested shouldn't work.
At what time exactly is the separate thread used for completion
callback stopped?
From 10.0-10.4 the thread, once created via a call to MIDISendSysEx,
never stops.
Doug
--
Doug Wyatt
Core Audio, Apple
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden