oops! Definitely should have obtained the latest version first. Indeed, the version I have been using is old and does not have the critical section.
Thanks a bunch! Adam On Thu, Mar 13, 2008 at 7:23 AM, Roger Dannenberg <[EMAIL PROTECTED]> wrote: > 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
