8000 Introduce IAsyncDalamudPlugin to tidy up plugin lifecycle by goaaats · Pull Request #1905 · goatcorp/Dalamud · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

Introduce IAsyncDalamudPlugin to tidy up plugin lifecycle #1905

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

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

goaaats
Copy link
Member
@goaaats goaaats commented Jul 7, 2024
edited
Loading
  • Introduces IAsyncDalamudPlugin to tidy up plugin lifecycle
  • Makes sure that calling UnloadAsync() or LoadAsync() don't block the main thread unnecessarily

TODO: LoadSync plugins and LoadRequiredState - does this "just work"? Should investigate before obsoleting old interface

@goaaats goaaats requested a review from a team as a code owner July 7, 2024 11:57
@KazWolfe
Copy link
Member
KazWolfe commented Jul 7, 2024

What's the intent for plugin lifecycle, then? I'd assume it's ctor, LoadAsync, , UnloadAsync, Dispose? In this case, this would also mean that the plugin's ctor would also be called in a random thread, yes? I'd like to see a broad list of things we'd want in the ctor vs LoadAsync in either case.

If so, I'm not certain we need to create a new interface for this. Would it be sensible to just place these new methods into IDalamudPlugin and assign a default implementation to them until we're ready to force people to do more async work?

@goaaats
Copy link
Member Author
goaaats commented Jul 7, 2024

LoadAsync is really just for convenience. People have asked for it and there's no reason not to have it. The main reason for the new interface is implementing IAsyncDisposable instead and forcing people to rethink their disposal scheme.

@KazWolfe
Copy link
Member
KazWolfe commented Jul 7, 2024

LoadAsync is really just for convenience. People have asked for it and there's no reason not to have it.

Would still be good to document when and why it should be used I think. I agree it's useful to have, but having two entrypoints can be a bit confusing alone.

The main reason for the new interface is implementing IAsyncDisposable instead and forcing people to rethink their disposal scheme.

Point taken. I'd ask we plan to refactor IAsyncDalamudPlugin back to just IDalamudPlugin in the future then, since the Async descriptor would become redundant if we're pushing everyone into async territory.

@Critical-Impact
Copy link
Contributor

Is there a risk that a plugin fails to complete it's DisposeAsync in a timely manner(or never completes) and if that happens should we have a timeout? (Apologies if there is one, I had a look through and I couldn't see one)

@KazWolfe
Copy link
Member

Think this is good for api12 targeting, though it needs to be rebased to the api12 branch.

What'll our strategy be for migration? I'd still like to see us collapse down to just async, but we'd need to decide naming. Perhaps just soft-obsolete IDalamudPlugin and keep the IAsyncDalamudPlugin name forever? Or do the aforementioned rename come api13?

@KazWolfe KazWolfe added plugin-api About or affects the Plugin API and removed api12-tracking labels Mar 26, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
plugin-api About or affects the Plugin API
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants
0