AW: Must multimedia players check the message queue and invoke DispatchMessage?

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

Hi,

Juan Lang wrote:
>Are you concerned about the applications introducing deadlocks by not
>servicing messages quickly enough, or about MCI introducing deadlocks
>by not processing messages in the current thread?

I was concerned both about the MCI and the rest of winmm (midi*, wave*) API.
We've a few bug reports about apps that hang but work with a native msvfw32.dll.
I'm wondering if that could be related (erk, another dll that I'm not familiar with).

>If the latter, this probably requires that MCI pump the message loop
>while it's processing.
The MCI API explcitly acknowledges some need for message pumping in the MCI_WAIT case via
the mciSetYieldProc function. MSDN says that the MCI drivers must periodically call it.
None of Wine's MCI drivers do.

It's unclear to me why it should be called. Once I read that it's used to be able
to react to the Break key to abort an animation (few people care).
Maybe it's also needed to continuously dispatch messages (refresh, resize, buttons etc.)?

I found no similar information about the wave* and midi* functions.
Yet testing indicates that they also hijack the application's thread since w2k,
possibly for as long as there's audio to play.
Perhaps there's no documentation precisely because that changed since w2k,
all winmm documentation predates that and in w9x another thread was used
so there was no analogue to MCI_WAIT design issues.
Who could shed some light?


>It's common to require that applications continue to "pump" the message
>loop when calling some blocking function.  Modal dialog boxes continue
>to do so, for example.
Indeed, one of my colleagues has written a mono-threading multi-windowing application.
It rarely seems to hang, except when reading from CTAPI.
It must be full of nested callbacks and calls to DispatchMessage.

What do you mean exactly by "message pumping"? There are a few places in Wine
that call PeekMessage e.g. MCI_DefYieldProc, MMSYSTEM_MidiStream_MessageHandler,
but to me it looks like an error when that is not accompanied by DispatchMessageA/W
of all the messages that the local handler does not understand.
I'd expect DispatchMessage, not PeekMessage to invoke all the callbacks.
Isn't it an error for all loops executing on the app's thread?


>I wouldn't be surprised if some app expects that it can post messages
>from its callbacks.
MSDN on waveOutProc explicitly allows Post[Thread]Message.
wave* are forbidden (no waveOutWrite from within a WOM_DONE callback,
no midiOutClose, but there are logs in Bugzilla that show otherwise).

MSDN documents MMSYSERR_HANDLEBUSY
"The handle is being used simultaneously by another thread (for example, a callback thread)."
I've never seen that error. Yet it means that they are considering
detecting possible dead-locks and contentions.

Thank you,
 Jörg Höhle