mciqtz32: Guarantees that CoInitialize and CoUninitialize run on the same thread.

[Akihiro Sagawa]

Hi Jörg,
Thanks for your comments.

On Fri, 29 May 2015 17:50:18 +0200, Jörg Höhle wrote:
> I would expect all MCI commands "STATUS POSITION" etc. to work while
> another thread is busy playing a file synchronously (using MCI_WAIT).
Good point.  I worried about this situation.  However, recent Windows
systems don't allow to call MCI commands from another thread.  Therefore,
this case might not happen.  I also considered to implement a sort of
corss-thread protection like native, but that breaks compatibilities for
Win9x and affects all devices.  Because I'm not sure about those effects,
I left the issue.  Do you know the application which relies on this
feature?

> Furthermore
> +static LRESULT MCIQTZ_relayTaskMessage [...]
> +    if (WaitForSingleObject(wma->task.done, INFINITE) == WAIT_OBJECT_0)
> 
> Are you sure it's ok to block the user thread like this? Shouldn't the code use a loop
> that also pumps the MS-Windows message queue and dispatches messages?
> E.g. there may be a need to dispatch REFRESH and PAINT messages?
Blocking is not a good idea in general.  I'll update the code to do the
things more asynchronously.

> Did you cross-check what MS-Windows does here?
I didn't check Windows behavior at that point.  IMHO, MCI code doesn't
assume the Window message queue and shouldn't touch them. I'll check the
behavior later.

> On a related note, IIRC some wine devices use a more reliable approach to waiting:
> WaitForMultiple(2 objects: [task.done, task.threadId], INFINITE);
> That way, should the player crash or exit somehow, the main (user) task doesn't hang.
Good catch. I'll use more reliable way.

Thanks,
Akihiro Sagawa