Callback version of PortMidi for Windows, bad idea?

[cogled4]

I needed a callback version of PortMidi for my Windows app. I modified the library to accept a callback function when opening a midi input stream. Then, in the Windows implementation, I call this callback instead of inserting the PmEvent into the queue.

For my purposes this seems to work well, the queue stays empty and I get the PmEvent's, both short and Sysex, sent straight to my callback function. Of course this isn't portable and I'm not recommending anyone else do this :) But I did want to ask, should I anticipate any major problems with this approach? It looks like the Windows Midi callback does use EnterCriticalSection() and LeaveCriticalSection(). I need to do more research about what that entails.

Forgive me if I'm posting this question in the wrong place. I couldn't find any Portmidi forum anywhere else.

[rbdannenberg]

What do you do in your callback? The callback is not running under your application thread, so if it reads or writes anything in your application that might also be read or written by the application, then you can expect non-deterministic and probably wrong behavior, but it won't happen often, so it will be hard to detect or debug. If you use critical sections correctly, you can probably avoid wrong behavior, but it can be hard to get right and even harder to test. The safest thing you could do is probably to put incoming MIDI into a data structure to be safely processed later by the application, but that's exactly what PortMidi does already. The other problem is priority inversion: Suppose you use critical sections and your application holds the lock and some other application is running at an intermediate priority between that of the MIDI callback and the application. This unknown intermediary process can remain busy indefinitely, effectively blocking the MIDI callback that has higher priority. I don't know what priority is given to the MIDI callback or what happens if it is blocked for an unusual amount of time, and I don't think Microsoft documents this or makes any promises, which is why PortMidi takes a safer and more portable implementation strategy (it's also free from priority inversion issues).