Re: Avoid a possible deadlock when stopping playback

[Christian Costa]

Hi Dmitry,
Are you sure this is usefull.
How can SetEvent cause a deadlock?
Bye,
Christian
> Message du 16/03/04 14:54
> De : Dmitry Timoshkov 
> A : [e-mail]
> Copie à : 
> Objet : Avoid a possible deadlock when stopping playback
> Hello,
>
> looks like it's a good idea to do the same when signalling hStopEvent.
>
> Changelog:
> Dmitry Timoshkov 
> Avoid a possible deadlock when stopping playback.
>
> --- cvs/hq/wine/dlls/winmm/mciavi/mciavi.c 2004-03-16 18:37:03.000000000 +0800
> +++ wine/dlls/winmm/mciavi/mciavi.c 2004-03-16 19:38:42.000000000 +0800
> @@ -606,7 +606,9 @@ static DWORD MCIAVI_mciStop(UINT wDevID,
> switch (wma->dwStatus) {
> case MCI_MODE_PLAY:
> case MCI_MODE_RECORD:
> - LeaveCriticalSection(&wma->cs);
>
> SetEvent(wma->hStopEvent);
> - EnterCriticalSection(&wma->cs);
>
> /* fall through */
> case MCI_MODE_PAUSE:
> /* Since our wave notification callback takes the lock,

Avoid a possible deadlock when stopping playback

[Dmitry Timoshkov]

"Christian Costa"  wrote:
> Are you sure this is usefull.
> How can SetEvent cause a deadlock?

That's exactly the same case your recent patch has fixed.
If the MCI command was sent asynchronously (without MCI_WAIT)
an thread gets created and the command gets executed there.

So, if an app does:
mciSendCommand(MCI_PLAY); // an async thread gets created
and right after that:
mciSendCommand(MCI_STOP);

last command hangs forever.

Avoid a possible deadlock when stopping playback

[Christian Costa]

Dmitry Timoshkov wrote:
> "Christian Costa"  wrote:
> > Are you sure this is usefull.
> > How can SetEvent cause a deadlock?
>
> That's exactly the same case your recent patch has fixed.

My patch was intended to fix a deadlock with the thread of the wave 
driver not with the async one.
SetEvent causes a reschedule in Wine (since it does a call to the 
server) that may help avoiding a deadlock
but this only hides the problem.
> If the MCI command was sent asynchronously (without MCI_WAIT)
> an thread gets created and the command gets executed there.
>
> So, if an app does:
> mciSendCommand(MCI_PLAY); // an async thread gets created
> and right after that:
> mciSendCommand(MCI_STOP);
>
> last command hangs forever.

Do you have a test app?

BTW, I've found more wave calls to "protect", will send a patch. :-)

Bye,
Christian

Avoid a possible deadlock when stopping playback

[Dmitry Timoshkov]

"Christian Costa"  wrote:
> > If the MCI command was sent asynchronously (without MCI_WAIT)
> > an thread gets created and the command gets executed there.
> >
> > So, if an app does:
> > mciSendCommand(MCI_PLAY); // an async thread gets created
> > and right after that:
> > mciSendCommand(MCI_STOP);
> >
> > last command hangs forever.
>
> Do you have a test app?

Yes. It's PowerPoint XP.
> BTW, I've found more wave calls to "protect", will send a patch. :-)

Good :-)