* Hide scheduler from RunOnFrameworkThread
Creating new tasks via Task.Run and alike would fetch the current
scheduler, which we do not want in case of running stuff from the
framework thread. Change is to prevent the standard library from seeing
the "current scheduler". If one wants to use `await` with an async
function to be run in the framework thread, one can use
`RunOnFrameworkThreadAwaitable` instead now.
* TaskSchedulerWidget: test better stuff
* TaskSchedulerWidget: add freeze tests
* More comments
* Make TaskFactory a getter method instead of property to avoid bad suggestions
* Why are there stuff still not pushed
* Add IInternal/PublicDisposableService
Plugins are exposed interfaces that are not inherited from
`IDisposable`, but services implementing plugin interfaces often
implement `IDisposable`. Some plugins may try to call
`IDisposable.Dispose` on everything provided, and it also is possible to
use `using` clause too eagerly while working on Dalamud itself, such as
writing `using var smth = await Service<SomeService>.GetAsync();`. Such
behaviors often lead to a difficult-to-debug errors, and making those
services either not an `IDisposable` or making `IDisposable.Dispose` do
nothing if the object has been loaded would prevent such errors. As
`ServiceManager` must be the only class dealing with construction and
disposal of services, `IInternalDisposableService` has been added to
limit who can dispose the object. `IPublicDisposableService` also has
been added to classes that can be constructed and accessed directly by
plugins; for those, `Dispose` will be ignored if the instance is a
service instance, and only `DisposeService` will respond.
In addition, `DalamudPluginInterface` and `UiBuilder` also have been
changed so that their `IDisposable.Dispose` no longer respond, and
instead, internal functions have been added to only allow disposal from
Dalamud.
* Cleanup
* Postmerge fixes
* More explanation on RunOnFrameworkThread(ClearHooks)
* Mark ReliableFileStorage public ctor obsolete
---------
Co-authored-by: goat <16760685+goaaats@users.noreply.github.com>
* Accommodate nested AddonLifecycle event calls
The game is free to call event handlers of another addon from one addon,
but the previous code was written under the assumption that only one
function may be called at a time. This changes the recycled addon args
into pooled args.
* Always clear addon name cache
As some public properties of `IGameConfig` are being set on the first
`Framework` tick, there was a short window that those properties were
null, which goes against the interface declaration.
This commit fixes that, by making those properties block for the full
initialization of the class.
A possible side effect is that a plugin that is set to block the game
from loading until it loads will now hang the game if it tries to access
the game configuration from its constructor, instead of throwing a
`NullReferenceException`. As it would mean that the plugin was buggy at
the first place and it would have sometimes failed to load anyway, it
might as well be a non-breaking change.
* Change MemoryHelper to allocate less
* Use StringBuilder pool for ReadSeStringAsString
* fix
* Use CreateReadOnlySpanFromNullTerminated where possible
* fix: Make auto-update work again, the lazy way.
- Move auto-update to run on the first `Notice` message for parity with the welcome message.
- Add some logging in a few critical places to make things nicer.
* fix overzealous IDE complaints
* code-review comments
- Remove stray imports that the IDE included
- Remove fixme to move auto-updates (for now)
* Lazy retry auto-update
* Actually make AddonEventManager thread safe
* Ensure AddonEventHandlers are also thread safe
Additionally, use Guid instead of strings
* Make DalamudInternalKey readonly
* Properly use ConcurrentDict features
Fixes GUID not working
