mupen64plus/mupen64plus-rsp-hle — pull request #16 by bsmiles32 (2014-03-06 10:09:04+00:00)
Title: Avoid global state

@richard42: please do NOT merge it now. I made the pull request only to allow multiple people to comment on this in a central place.

@all:
Initially the HLE rsp plugin was developped only for mupen64plus needs and didn't care about global state and plugin interface dependency. This work attempts to play better with third parties which would like to integrate our code into their project.

The first feature of this work is the separation of "core" hle (ie everything except plugin.{c,h}), from mupen64plus specific needs (ie plugin.{c,h}). Now the "core" hle doesn't depend on m64p (be it header files, or function prototypes). The glue between m64p and core hle is done in plugin.{c,h}.

The second feature is that "core" hle don't have any global state variables anymore. It instead passes a struct hle_t pointer around. This allow to instanciate many hle within the same process, for example for an audio player or alist debugger...

Because of the structure passing, instead of global variable, I expected a performance hit, but I couldn't observe it on my machine. However I'd be interested if other notices performance drop. (Usually the bottleneck is on the video plugin anyway...).

Intended usage:
Third parties, shouldn't modify "core" hle, al their customization should o to plugin.{c,h}.
For instance, if in your app you don't wan't {Warn,Error,Verbose} messages, just redefine Hle*Message accordingly (even with nullifying macros if you want).
If you don't care about the plugin interface specification, just rewrite the plugin.c file to setup the hle_t struct to your convenience and call hle_execute with it.

Benefits:
-core can be used independently of the m64p project
-should ease synchronization between forks (only plugin.{c,h} should differ)
-should allow better customization by other projects

Drawbacks:
-massive change
-can potentially bring a performance hit

Please discuss.