Use CoreTiming for MemoryWatcher.

[spxtr]

It might be worth moving some code from Core.cpp into MemoryWatcher.cpp. Let me know.

---

This change is

[JosJuice]

Is there any particular reason for this change? Determinism? Simplicity?

---

Review status: 0 of 3 files reviewed at latest revision, 2 unresolved discussions.

---

Source/Core/Core/Core.cpp, line 118 [r1] (raw file):
Please use longer names. fps is fine to use as an acronym (though it's inaccurate in this case – MemoryWatcher callbacks are not frames), but mw should be memory_watcher, and I don't even know what et is supposed to be.

---

Source/Core/Core/Core.cpp, line 123 [r1] (raw file):
You might want to subtract cyclesLate from the next callback's delay.

---

Comments from Reviewable

[degasus]

In my opinion, there is no need to ask why something should be deterministic. As long as there is no good reason not to be so, everything should be determinnistic ;)

So I like this change. A dummy thread is dropped, a race condition is dropped (you had accessed the GC memory in a unsafe way). But yeah, moving more code into MemoryWatcher.cpp would be nice.

[JosJuice]

Indeed, it's better to have this deterministic. I was just asking because it wasn't clear at first that determinism was the reason for this change.

[spxtr]

Determinism is nice, but the real reason is that I want to run it at roughly 5x speed, and polling at a fixed time interval wasn't good enough for that.

Thanks for the comments, PTAL.

---

Review status: 0 of 3 files reviewed at latest revision, 6 unresolved discussions.

---

Source/Core/Core/Core.cpp, line 118 [r1] (raw file):
Ok, picked some better names. I took et from SystemTimers.cpp.

---

Source/Core/Core/Core.cpp, line 123 [r1] (raw file):
Done.

---

Source/Core/Core/Core.cpp, line 123 [r1] (raw file):
Done.

---

Source/Core/Core/Core.cpp, line 299 [r1] (raw file):
Done.

---

Source/Core/Core/Core.cpp, line 372 [r1] (raw file):
Done.

---

Source/Core/Core/MemoryWatcher.cpp, line 85 [r1] (raw file):
I still want it because if there is no Locations.txt or if the socket doesn't open then I want to skip this. It's certainly possible to get that behavior by only scheduling the event if loading is successful, but this was easier.

---

Comments from Reviewable

[JosJuice]

Review status: 0 of 3 files reviewed at latest revision, 7 unresolved discussions.

---

Source/Core/Core/MemoryWatcher.cpp, line 25 [r2] (raw file):
Shouldn't this be SystemTimers::GetTicksPerSecond() / MW_RATE - cyclesLate?

---

Comments from Reviewable

[spxtr]

Review status: 0 of 3 files reviewed at latest revision, 7 unresolved discussions.

---

Source/Core/Core/MemoryWatcher.cpp, line 25 [r2] (raw file):
Done.

---

Comments from Reviewable

[degasus]

Reviewed 2 of 3 files at r2, 1 of 1 files at r3.
Review status: all files reviewed at latest revision, 3 unresolved discussions.

---

Comments from Reviewable

[JosJuice]

Please squash the commits.

---

Review status: all files reviewed at latest revision, all discussions resolved, some commit checks pending.

---

Comments from Reviewable

[spxtr]

Done.

---

Review status: all files reviewed at latest revision, all discussions resolved, some commit checks pending.

---

Comments from Reviewable

[degasus]

LGTM. IMO fine for 5.0.

---

Review status: all files reviewed at latest revision, all discussions resolved, some commit checks pending.

---

Comments from Reviewable

[vladfi1]

So it happens that I came up with a different solution to this almost a year ago at https://github.com/vladfi1/dolphin - instead of having a separate thread periodically checking, I had a hook from VideoInterface::EndField that would poll once each frame. Doing this on SSBM gave me no missed frames under a lot of different conditions. Would that be preferable to the current approach?

I also turned made the memory watcher use zmq (for synchronization) - if we did the same with the named pipes I think that would be enough for windows compatibility.