What will happen if the module fail? about sm-zombiereloaded

[rhelgeby]

Currently, all modules are responsible for releasing resources they allocate.

Modules are individual SourceMod plugins. When it's unloaded, the resources (handles) it allocated by itself (from within the plugin) will be closed. A module may request resources in other modules, such as creating events or defining resources in my resource manager module. These modules allocate their own resources and pass handles to modules that requested the resources.

When the module is unloaded it has to release resources it allocated from other modules, because SourceMod doesn't know it did that. The event manager and others also doesn't know if the module is unloaded and will leak memory.

This is one of the reasons I need access to a plugin listener in SourceMod so plugins can know when another plugin is removed. If we get this, then I can guarantee that it will clean up after bad modules. Without it, modules are responsible for cleanup.

We have OnLibraryAdded and OnLibraryRemoved but that requires every module to register itself as a library. The module manager and event manager use this so feature modules can detect when it's available or unavailable.

I could make this strict and require that all feature plugins that registers as a ZR module also is a library, so the module manager can listen for changes.

There's another case that may leak memory. That is when a module do something that cause an error and aborts the call. During that call it may have allocated resources, but they will leak due to the error. The leak will most likely be slow, depending on the error rate. This case applies to all SourceMod plugins.

Memory management is an issue, so we'll probably see the first leaks in core modules like the module manager, event manager or resource manager. I've tried to make bootstrap helpers that will gracefully unload a module, so as long as we use a bootstrapper in all modules it should be manageable.

[LivingInPortal]

I see, but I think this is not a way out.

IMHO:

This is going to reduce a lot of convinence and hard to debug for both devs and admins.
(In extreme situation)If a server loads tons of modules and the one is broken or not well-designed, server explodes, and admin will never know why just because the plugin gives a lot of shit to zombiereloaded.
I think in this architecture, zombiereloaded is not a plugin anymore but an extension.
Why not just give a zombiereloaded a helper extension so that you can expand your code in sourcepawn and get internal hook in c++?
I can't see any merit in just a sourcepawn

[rhelgeby]

Yes, your PluginStatusForward extension might be enough. As long as it's easy enough to maintain, compiles on all platforms and doesn't break on game updates (not likely I assume, since it's not using anything engine-specific).

In case of a badly written plugin, the worst that could happen regarding memory is that SourceMod will detect a leak and unload that plugin. The server should not crash because of this.

Memory usage in general is not a major concern, since it won't be much (a wild estimate is probably far less than 20 MB for data, not the code), and that is affordable. My object library add some overhead due to meta data it's storing, but it's not much if it's used wisely. A memory leak is a different story, but SourceMod should handle this pretty well.

I do agree that even the entire module framework is suitable as an extension. I choose to keep it at the SourcePawn level to keep it simple (less complicated compilation and development environment).

I can do proper memory management in modules if I only get access to the plugin listener events, so the helper extension seems to be the way to go now.

Otherwise this issue is not a major priority. It's more important to get a working prototype with well-behaving modules so I can start gradually migrating ZR.