Run the AddOnManager after having loaded add-ons on the InputServer

thread. After fixing the internal locking of AddOnMonitorHandler in
r38235, running the AddOnManager before scanning add-ons could lead
to a dead-lock in case devices appeared while the input_server was
still initializing. This hopefully fixes #6760 and possibly also
#6819. I've tested in both qemu and on real hardware (quad-core with
3 mice, one tablet and 3 keyboards connected). I've also tested
hot-plugging devices, which still works as expected. The problem may
have already been fixed in the preceding changeset, by elliminating
an extra involved looper. Since node monitor messages were actually
received on the wrong looper, using the looper lock in AddOnManager
did not have the intended effects.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@39742 a95241bf-73f2-0310-859d-f6bbb57e9c96

src/servers/input/InputServer.cpp

@@ -183,8 +183,16 @@ InputServer::InputServer()
 
 	fAddOnManager = new(std::nothrow) ::AddOnManager(SafeMode());
 	if (fAddOnManager != NULL) {
-		fAddOnManager->Run();
+		// We need to Run() the AddOnManager looper after having loaded
+		// the initial add-ons, otherwise we may deadlock when the looper
+		// thread for some reason already receives node monitor notifications
+		// while we are still locked ourselves and are executing LoadState()
+		// at the same time (which may lock the add-on looper thread).
+		// NOTE: At first sight this may look like we may loose node monitor
+		// notifications while the thread is not yet running, but in fact those
+		// message should just pile up and be processed later.
 		fAddOnManager->LoadState();
+		fAddOnManager->Run();
 	}
 
 	BMessenger messenger(this);