Skip to content

Conversation

@goaaats
Copy link
Member

@goaaats goaaats commented Jul 7, 2024

  • 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
Member

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