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