[Scummvm-devel] Less memory-aggressive plugin management

Max Horn max at quendi.de
Fri Nov 9 15:30:51 CET 2007


On Fr, November 9, 2007 14:43, Kostas Nakos wrote:
> OK,
>
> Here are some thoughts and points of view expressed in the channel:
>
> Initial research shows that the "naive" method of loading each plugin,
> caching some info and then discarding them will not work out of the box.
> In particular, the only thing that can be cached is the data returned
> from the game####list of each engine, which according to our api is
> "just for show" and not meant for real detection. The actual detection
> is carried out at findgameid(), which is a proper function and cannot be
> cached.

Indeed, true.

>
> So that leaves us with:
>
> Max Horn wrote:
>> A more elaborate, but also more complicated approach, would be to split
>> all plugins into two parts/plugins: One containing the detection code,
>> and
>> one containing the rest of the code. This *should* work (at least for
>> most
>> of our engines), assuming the engine implements detection sanely.
>
> Since (at least) DC has a problem with this,
Hu, it does? I understood Marcus as saying: "This will not benefit the DC
backend", not as "this won't work on the DC". Specifically: "However,
there's no potential to use the split approach you describe here to speed
up the DC port. "

But I am sure Marcus will correct me if I am wrong :-).


> we need to have support for
> plugins both ways. E.g. as it is right now and a reduce memory version
> with 2 separate plugin-files for each engine. The mode of plugin loading
> (single or 2 files) can be determined either at runtime (load the
> detection plugin, if it fails try the engine plugin) or at compile time.
>
> The other thing of course is to partially redesign the plagin interface
> so that the game info can be read from the engine plugins and allow it
> to be cached for use.

That won't work, because detection is something that is performed by code,
not via a static lookup. So, essentially, we have three choices:

1) Go on as we do now; maybe add some code to (un)load plugins more often,
but that's it.

2) Split plugins into two parts, detection and engine. Complicates the
build system and the loading code

3) Blur the strict separation between plugins and the core app, by static
linking the detection code into the main binary. This would be a lot
easier to implement, I guess. Obvious drawbacks: Can't unload the
detection code (but that should be a minor issue), and a user can't
dynamically add new plugins which were not known at compile time -- but
that's not really a useful/important feature, as long as we don't define a
clear API for engine plugins.

To implement 2) or 3), the build system would have to be modified: Do not
link engines/FOO/detection.o (or whatever file(s) contains the detection
code) into the engine plugin, but rather into the a separate plugin, or
the core binary. To make that possible, the detection code of course would
have to be completely isolated from the engine code. Regarding the plugin
API, that would mean that the engine instantion code would be moved to the
"engine plugin" (and out of detection.cpp).



Bye,
Max




More information about the Scummvm-devel mailing list