[Media_api] Brief PortMidi Question

[Adam Somers]

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 <rbd at cs.cmu.edu> 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.
>
>