Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Pause dependent plugins on SetFailState (bug 6120) #93

Merged
merged 2 commits into from
Jan 3, 2015

Conversation

peace-maker
Copy link
Member

When a plugin calls SetFailState it is paused and all natives it
registered are unavailable. Other plugins, which depend on those natives
keep running and error whenever they try to call those natives.

This correctly sets the dependent plugins to an error state and also calls OnLibraryRemoved correctly for all libraries as if the
plugin which called SetFailState was unloaded.

As a sideeffect OnPluginPauseChange is called again, when a plugin changes its pause state.

@peace-maker
Copy link
Member Author

I'd like to see this 1.6.1!
@asherkin @dvander

@@ -376,7 +376,7 @@ static cell_t SetFailState(IPluginContext *pContext, const cell_t *params)

if (params[0] == 1)
{
pPlugin->SetErrorState(Plugin_Error, "%s", str);
pPlugin->SetErrorState(Plugin_Failed, "%s", str);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These should stay as Plugin_Error, I think... if it's Plugin_Failed, we assume the error was so severe that we can't perform diagnostics (like say, the underlying plugin structure may be read as corrupt, so sm plugins info <N> will display a very abbreviated listing). Since that's not the case here, "Error" should be good enough.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see, i tried to avoid changing the signature of CPlugin::SetErrorState and still be able to DropEverything only when the plugin is not going to resume.

I could live with that drawback of less info in sm plugins info.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hrm, I don't understand that comment.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The whole point of this PR is to call DropEverything on the plugin which is paused by the SetFailState native.
It does this by passing the Plugin_Failed status to CPlugin::SetErrorState, which was modified to drop everything, if called with Plugin_Failed.
SetErrorState also calls CPlugin::SetPauseState now instead of only CPluginManager::_SetPauseState, so the libraries of the plugins are updated with the OnLibrary(Added|Removed) forwards (and OnPluginPauseChange is called).

We could still change the signature of SetErrorState to include another boolean which controls calling of DropEveryhing to pause dependent plugins, but i tried to avoid changing the intercom system.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Bleh... the status code stuff is such a mess. Okay, if we go this route then, it would be good to change:

https://github.com/alliedmodders/sourcemod/blob/master/core/logic/PluginSys.cpp#L1141

That to Plugin_BadLoad, and..

https://github.com/alliedmodders/sourcemod/blob/master/core/logic/PluginSys.cpp#L2220
https://github.com/alliedmodders/sourcemod/blob/master/core/logic/PluginSys.cpp#L2243

These two include Plugin_Failed.

This way the meaning of "Failed" becomes "An error that is unrecoverable" and the most severe existing uses of "Failed" become "unloadable plugin."

@dvander
Copy link
Member

dvander commented Oct 21, 2014

The rest looks fine, though I'm guessing we could just remove OnPluginPauseChange (do we even support pausing anymore?)

@peace-maker
Copy link
Member Author

Internally plugins still get paused by the dependency system. You can't do sm plugins pause x anymore though, so the user can't control pausing.

I yet have to see a plugin that handles pausing itself with that forward, but if there are still cases that would have this called, i'd just leave it in.

@dvander
Copy link
Member

dvander commented Oct 27, 2014

That actually sounds like a pretty good argument for removing the callback, not keeping it ;) but since it's unrelated to this bug it's fine to keep it as-is.

@peace-maker
Copy link
Member Author

Changed the usage of Plugin_Failed as you suggested.

@dvander
Copy link
Member

dvander commented Nov 20, 2014

@peace-maker I think this has needed a rebase - should be good to go otherwise though.

When a plugin calls SetFailState it is paused and all natives it
registered are unavailable. Other plugins, which depend on those natives
keep running and error whenever they try to call those natives.

This correctly sets the dependent plugins to an error state as if the
plugin which called SetFailState was unloaded.
Change the meaning of Plugin_Failed status to indicate, that the plugin
can't recover from the error.
Make sure those previously loaded plugins are shown correctly in sm
plugins info x.
@peace-maker
Copy link
Member Author

Good to go

dvander added a commit that referenced this pull request Jan 3, 2015
Pause dependent plugins on SetFailState. (bug 6120, r=dvander)
@dvander dvander merged commit bf3ff46 into alliedmodders:master Jan 3, 2015
@peace-maker peace-maker deleted the failstate_dependencies branch January 3, 2015 19:50
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants