search

divyang4481 / bizhawk

Automatically exported from code.google.com/p/bizhawk
0 stars 0 forks source link

N64 - minimize all / restore all doesn't work correctly #233

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
r7431 and below

See this video for details: https://www.youtube.com/watch?v=tAEyKcbiNp4
I couldn't find a screen recorder that recorded audio well, so just imagine an 
error sound every time I click something.

Only happens on N64, works as intended with every other core. I tested NES, 
zeromuisan tested with NES and SNES.

zeromuisan was also able to reproduce this with N64.

Original issue reported on code.google.com by moritz.g...@gmail.com on 28 Jul 2014 at 10:48

GoogleCodeExporter commented 9 years ago 
I was able to reproduce this in Windows 7 Professional. It happened with Rice, 
Glide64, Glide64mk2, and Jabo as the video plugin. I unhid the Jabo hidden 
window (changed SW_HIDE to SW_NORMAL) and still had the problem. I changed my 
Windows theme to Windows Classic (turning off aero), and still had the problem.

Original comment by pjga...@gmail.com on 3 Aug 2014 at 12:42

GoogleCodeExporter commented 9 years ago 
Braindump:

Sometimes the message from the taskbar will be sent while the n64 core goes 
into a synchronization WaitOne() call for the n64 emulator to proceed. When 
this happens, it is actually handled by a message pump underneath WaitOne()! 

You can read more about it in the links I appended.

The taskbar messages getting received by the message pump underneath the 
WaitOne call seem to be what are malfunctioning here. I'm not really sure why. 
Perhaps that could be debugged. If it could be done, it would be a better 
solution than what I'm committing. However, it's really hard. I think the bug 
is in unmanaged CLR internals.

Workaround 1: instead of .net WaitOne(), call pinvoke WaitForSingleObject() 
which doesnt pump the message queue.

Theoretically without the message queue getting pumped, things could hang or 
deadlock, and the system (the whole system! yay, windows) could get kind of 
clunky. However.. we happen to know that (usually) we wont block for long. 
Nonetheless... in case lua fires hook callbacks.. maybe we could be in real 
trouble.

Workaround 2: Attempt to do what we think CLR is doing, but with less 
malfunctioning black magic (who knows what else it breaks?) It's based on 
https://raw.githubusercontent.com/noserati/tpl/master/ThreadAffinityTaskSchedule
r.cs

I think the proper way to solve this is to slit your wrists. While you bleed to 
death, turn your user interface code inside out and make it all asynchronous. 
We are never going to do this.

I'm calling this fixed, even though its just workarounded. If we ever slit our 
wrists, it wont be in the context of this bug.

Useful notes:

http://stackoverflow.com/questions/4540244/how-is-this-possible-onpaint-processe
d-while-in-waitone

http://social.msdn.microsoft.com/Forums/vstudio/en-US/da11c1a2-eed3-4b44-ba1d-7a
9c1e4c0588/deadlock-when-using-waitone-in-a-sta-thread?forum=clr

http://stackoverflow.com/questions/21571598/which-blocking-operations-cause-an-s
ta-thread-to-pump-com-messages

https://raw.githubusercontent.com/noserati/tpl/master/ThreadAffinityTaskSchedule
r.cs

Original comment by zero...@zeromus.org on 14 Sep 2014 at 9:07