LilyPad: Bugfixed cause of occasional hangs and lost input. Also, I've implemented an experimental fix for Issue 458 (laggy/sticky controls every 10-20 seconds).

git-svn-id: http://pcsx2.googlecode.com/svn/trunk@2082 96395faa-99c1-11dd-bbfe-3dabce05a288

plugins/LilyPad/LilyPad.cpp

@@ -25,6 +25,10 @@
 HINSTANCE hInst;
 HWND hWnd;
 
+// Keeps the various sources for Update polling (PADpoll, PADupdate, etc) from wreaking
+// havoc on each other...
+CRITICAL_SECTION updateLock;
+
 // Used to toggle mouse listening.
 u8 miceEnabled;
 
@@ -381,6 +385,19 @@ char padReadKeyUpdated[4] = {0, 0, 0, 0};
 #define LOCK_BUTTONS 4
 #define LOCK_BOTH 1
 
+struct EnterScopedSection
+{
+	CRITICAL_SECTION& m_cs;
+
+	EnterScopedSection( CRITICAL_SECTION& cs ) : m_cs( cs ) {
+		EnterCriticalSection( &m_cs );
+	}
+	
+	~EnterScopedSection() {
+		LeaveCriticalSection( &m_cs );
+	}
+};
+
 void Update(unsigned int port, unsigned int slot) {
 	char *stateUpdated;
 	if (port < 2) {
@@ -390,28 +407,50 @@ void Update(unsigned int port, unsigned int slot) {
 		stateUpdated = padReadKeyUpdated+port-2;
 	}
 	else return;
+
 	if (*stateUpdated > 0) {
 		stateUpdated[0] --;
 		return;
 	}
 
+	// Lock prior to timecheck code to avoid pesky race conditions.
+	EnterScopedSection padlock( updateLock );
+
 	static unsigned int LastCheck = 0;
 	unsigned int t = timeGetTime();
 	if (t - LastCheck < 15 || !openCount) return;
 
-	if (windowThreadId != GetCurrentThreadId()) {
+	// pcsx2wx only -->
+	// The following codeblock is problematic on many systems.  Every 10-25 seconds LilyPad becomes unresponsive,
+	// or "sticks", for about a second.  I logged the FORCE_UPDATE handler and it seems to be executing
+	// consistently, even during the stuck second, so I'm really not sure why Lilypad gets stuck at all.
+	// I tried and checked just about every other variable here -- forcing all the stateUpdated's to 0,
+	// and setting the above LastCheck threshold to 5ms.  Some things made the behavior worse.  Nothing
+	// made it better. :(
+	//
+	// In addition to removing this block of code, I've installed a mutex lock (critical section) above,
+	// which fixes both this issue and a more serious issue that sometimes caused Lilypad to become
+	// completely unresponsive for extended periods (due to multiple threads reading and writing to
+	// LastCheck at the same time, corrupting its contents).  I'm not sure if this violates some rules
+	// or requirements regarding thread affinity and devices supported by lilypad (all online info
+	// indicates DInput is entirely safe, but I don't know about other device types).
+	//
+	//   --air
+	
+	/*if (windowThreadId != GetCurrentThreadId()) {
 		if (stateUpdated[0] < 0) {
 			if (!updateQueued) {
 				updateQueued = 1;
 				PostMessage(hWnd, WMA_FORCE_UPDATE, FORCE_UPDATE_WPARAM, FORCE_UPDATE_LPARAM);
 			}
-		}
-		else {
+		} else
+		{
 			stateUpdated[0] --;
 		}
 		return;
-	}
-	updateQueued = 0;
+	}*/
+
+	//updateQueued = 0;
 
 	LastCheck = t;
 
@@ -584,6 +623,7 @@ void Update(unsigned int port, unsigned int slot) {
 	for (i=0; i<8; i++) {
 		pads[i&1][i>>1].sum = s[i&1][i>>1];
 	}
+	
 	padReadKeyUpdated[0] = padReadKeyUpdated[1] = padReadKeyUpdated[2] = 1;
 	stateUpdated[0]--;
 }
@@ -648,6 +688,8 @@ void CALLBACK PADshutdown() {
 		pads[i&1][i>>1].initialized = 0;
 	portInitialized[0] = portInitialized[1] = 0;
 	UnloadConfigs();
+	
+	DeleteCriticalSection( &updateLock );
 }
 
 inline void StopVibrate() {
@@ -732,6 +774,8 @@ s32 CALLBACK PADinit(u32 flags) {
 	// Just in case, when resuming emulation.
 	ReleaseModifierKeys();
 
+	InitializeCriticalSection( &updateLock );
+
 	DEBUG_TEXT_OUT("LilyPad initialized\n\n");
 	return 0;
 }
@@ -926,6 +970,7 @@ s32 CALLBACK PADopen(void *pDsp) {
 			EatWndProc(hWnd, HideCursorProc, 0);
 		}
 		SaveStateChanged();
+		
 		windowThreadId = GetWindowThreadProcessId(hWnd, 0);
 	}