[asherkin]

Originally Posted by Chdata This is why I don't bother to try contributing anything to the SM team

I'm not sure why you're trying to incite a flame war, but stop. The only comment in this thread from a member of the SM team in regards to any suggestions presented here is Fyren suggesting the ownership relationship is backwards (which is correct).

As for Plugin handles, the Handle documentation states:

Plugin Handles should not be cached globally, as plugins can become unloaded, and the Handle will be invalid.

They should only be used within the forward they were retrieved (or passed as a parameter).

Trying to implement garbage collection into a language with no concept of destructors or finalizers and with explicit ownership is always going to be difficult - it was discussed back in 2009 and decided against for SM as a whole.

I see several viable paths forward for Dynamic:

• Dynamic stops trying to save badly written plugins from leaking memory (removing the "garbage collector"), maintains ownership of objects it creates so that other plugins unloading does release Handles out from under it. I think everyone would consider this sane, anyone writing plugins knows not to leak their handles.
• We add a way for plugins to register a new Handle type - with an associated destruction callback. This would allow Dynamic to be made aware when a plugin has unloaded, and encapsulate it's per-plugin resources in that Handle as well. Probably reasonable, would need a lot of discussion.
• Expose IPluginListener to plugins so Dynamic can clean up its own state. Probably not going to happen, it is fragile for this use case and is generally counter to plugin interdependency design in SourceMod.
• Make plugin handles cloneable, which would allow Dynamic to clone the plugin handles it caches and use them with at least GetPluginStatus after unload. I do not know how complex this would be to implement, but is probably the most likely option after "do nothing, change Dynamic".

[WildCard65]

Originally Posted by asherkin Expose IPluginListener to plugins so Dynamic can clean up its own state. Probably not going to happen, it is fragile for this use case and is generally counter to plugin interdependency design in SourceMod.

This option does exist in ExtraPLAPI, but the main purpose of the forwards was for getting pubvars when a plugin is loaded and setting the handles to null on plugin being unloaded (otherwise plugin would be referencing a freed handle).

[Neuro Toxin]

Originally Posted by asherkin Dynamic stops trying to save badly written plugins from leaking memory (removing the "garbage collector"), maintains ownership of objects it creates so that other plugins unloading does release Handles out from under it. I think everyone would consider this sane, anyone writing plugins knows not to leak their handles.

I just want to clarify that Dynamic owns all of it's Handles. Plugins using Dynamic simply get an ArrayList index to a master ArrayList which stores the base object data.

Plugin Handles should not be cached globally, as plugins can become unloaded, and the Handle will be invalid.

I'm breaking this.

As each Dynamic instance initialises, the calling plugin Handle parsed through the native is cached for persistence checks in the garbage collector.

This allows a plugin to load, generate a complex namespace/dataset and unload, while leaving persistent objects behind that wont be collected as garbage.

[Fyren]

What are you actually using the plugin handle for?

[Neuro Toxin]

OnMapEnd/OnLibraryRemoved
> loop dynamic objects
>> if plugin failed/errored/unloaded
>>> dispose object

Code is here

Edit:

line 246 has: dynamic.OwnerPlugin being parsed to GetPluginStatus

[Neuro Toxin]

Been thinking could I request:

bool GetPluginStatusEx(Handle plugin, PluginStatus &status);

Returns true if status found, return false on invalid handle.

[friagram]

It sounds like what you really need is the ability to call regpluginlibrary for another plugin.
This would be easy to do if a second arg were passed allowing for the plugin's handle to be specified...

[Neuro Toxin]

Then I have the opposite problem of having to hook OnPluginStart so I can force registration.

[friagram]

Originally Posted by Neuro Toxin Then I have the opposite problem of having to hook OnPluginStart so I can force registration.

https://sm.alliedmods.net/api/index....d=show&id=583&

[Neuro Toxin]

Aftee lots of thinking and trying to resolve my base issue I believe this is my most elegant solution.

Can someone confirm if this is an easy thing to accomplish. I've been looking at source but dont have a clue.