[PATCH 2/2] winmm: Make midiStream* messages asynchronous to avoid dead-locks. (try 2)

[Joerg-Cyril.Hoehle at t-systems.com]

Hi,

This fixes #26697 and a few other bugs where apps hang when
they use midiStream* from inside FUNCTION callbacks.
I believe bug #3930 is affected by waveOut callbacks, not midiStream or midiOut.

Since patch 1/2 it is safe to make midiStream* not wait for ack
because the entire communication is message based, unlike the
MCI that uses a status variable.
BTW, patch 1/2 works stand-alone.

Apps like to call midiStreamOut from within a MHDR_DONE callback.
This patch allows midiStreamSuspend/Resume/Stop to be called within such a callback.

As apps also use midiStreamClose from within such a callback, I've included
a FIXME so users are warned.  The patch then leaks the player structure,
allowing Close to succeed, which is what the apps expect.

The patch also fixes the Thread handle leak as well as a sort of
race condition that can occur because DriverCallback was called
while lpMidiStrm->lpMidiHdr was inconsistent.

In summary, DriverCallback DCB_FUNCTION is not perfect yet, but
it supports many more MIDI scenarios than before.

There are more bugs in midiStream handling.  For instance, the midiStream
PrepareHeader call should not be forwarded to midiOut because midiOut
has no business with the midiStream header object -- well, perhaps unless
the low-level driver supports MIDICAPS_STREAM, which Wine's do not.

Regards,
	Jörg Höhle
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0002-winmm-Make-midiStream-messages-asynchronous-to-avo.patch
Type: application/octet-stream
Size: 5520 bytes
Desc: 0002-winmm-Make-midiStream-messages-asynchronous-to-avo.patch
URL: <http://www.winehq.org/pipermail/wine-patches/attachments/20120210/3be44e70/attachment-0001.obj>