I'd like to retract my previous post. I should have read the code
instead of going by memory. Here's some relevant code from the beginning
of winmm_in_callback():
/* if this callback is reentered with data, we're in trouble. It's hard
* to imagine that Microsoft would allow callbacks to be reentrant --
* isn't the model that this is like a hardware interrupt? -- but I've
* seen reentrant behavior using a debugger, so it happens.
*/
EnterCriticalSection(&m->lock);
So yes, callbacks are reentrant, even with a single MIDI device open. I
believe PortMidi handles this in the best way. Adam reported some
reentrance detection code and an assert() -- this must be from an older
version of PortMidi. To update, please install SVN and follow the
instructions posted here:
http://portmedia.wiki.sourceforge.net/portmidi
This makes me wonder: if immediately after the first instruction of the
callback routine, the callback thread was preempted, what would prevent
another thread from delivering another MIDI message, which would then be
processed out-of-order? It seems the only way to prevent such a race
condition is for the system to make the callbacks non-reentrant, at
least on a per-device basis. (Alternatively, there could be a provision
for the callback to say "I've handled the message, you can call me
reentrantly now") I suspect this is a Microsoft bug, although I supposed
there could be some argument about scheduling and priorities that
prevents the race condition from causing problems in practice.
_______________________________________________
media_api mailing list
media_api@create.ucsb.edu
http://lists.create.ucsb.edu/mailman/listinfo/media_api
