* Added a deferred queue to the AZ Console class
An AZ Console instance will now store any console commands that could be
dispatched from a configuration file into a deferred queue, that can be
invoked later.
This can be used to defer execution of console commands in configuration files such as
.cfg, .setreg and .setregpatch files that are defined in gem modules that
have not been loaded yet.
The defered execution can then be invoked at any point later in the
application
Updated the Component Application CreateCommon function to invoke deferred console commands
after all the gems have loaded
fixes#2062
Signed-off-by: lumberyard-employee-dm <56135373+lumberyard-employee-dm@users.noreply.github.com>
* Fixed variable shadowing in the Console Deferred Command Test
Updated commit for the ClearDeferredQueue function to just mention
clearing the queue
Signed-off-by: lumberyard-employee-dm <56135373+lumberyard-employee-dm@users.noreply.github.com>
* Filtered out execution of the ConsoleRootCommandKey as a console command
The AZ::Console notification handler is tracking changes to the fields
of "/Amazon/AzCore/Runtime/ConsoleCommands" and it's children.
Now the "/Amazon/AzCore/Runtime/ConsoleCommands" field is the
ConsoleRootCommandKey and not an actual console command so it shouldn't
attempt to be invoked
Signed-off-by: lumberyard-employee-dm <56135373+lumberyard-employee-dm@users.noreply.github.com>
* Moved the execution of deferred console commands after linking deferred
functors
Signed-off-by: lumberyard-employee-dm <56135373+lumberyard-employee-dm@users.noreply.github.com>
* Moved the execution of deferred console commands into CreateModuleClass
hook
Any module that loads using the ModuleManager system will attempt to
execute any deferred console commands to allow newly registered commands
from that module to be dispatched.
Signed-off-by: lumberyard-employee-dm <56135373+lumberyard-employee-dm@users.noreply.github.com>
* Added a StealHandlers function to AZ Event
The StealHandlers function is able to take all the handlers from an AZ
Event parameter and register them with the current AZ Event
This allows stealing handlers from expiring AZ Events, which is useful
for a lock and swap algorithm for thread safety.
1. Lock persistent AZ::Event
2. Swap persistent AZ::Event with local AZ::Event
3. Unlock persistent AZ::Event - Other threads can now add to this
AZ::Event
4. Invoke handlers from local AZ::Event
5. Relock persistent AZ::Event
5. Swap local AZ::Event with persistent AZ::Event
6. Local AZ::Event now contains handlers that were added when the lock
was free
7. Persistent AZ::Event now steals from local AZ::Event
8. Unlock persistent AZ::Event
Signed-off-by: lumberyard-employee-dm <56135373+lumberyard-employee-dm@users.noreply.github.com>
* Separated SettingRegistry update/query mutex from Notifier update mutex
The Settings Registry update/query mutex is also better scoped to reduce
the amount of lock time.
The Notifier mutex being separate allows the Settings Registry to signal
a notification event without being under any mutex, by locking and
swapping the notifier event with a local instance
Signed-off-by: lumberyard-employee-dm <56135373+lumberyard-employee-dm@users.noreply.github.com>
* Renamed StealHandlers function to ClaimHandlers
Replaced decltype keywords in ClaimHandlers to auto
Signed-off-by: lumberyard-employee-dm <56135373+lumberyard-employee-dm@users.noreply.github.com>
Esteban Papp
puvvadar
lumberyard-employee-dm
Jeremy Ong
Jeremy Ong
pappeste
Danilo Aimini
Gene Walters