fix skillmanager and provider deadlocks when callingSubskills, query executionsatus and descriptions and stopping subskills at the same time
Found a deadlock when querying for statusUpdates or skillDescriptions while stopping for a skill (commit 9c6e909c).
Further, the Manager was using stop instead of stopAsync.
Also identified the following race conditions (which are not addressed on this branch):
- SkillRuntime (stop, updateParams) accesses the local member
skilland checks for NULL. If skill is set at the same time, this may cause a segfault (not sure though if the setting of the skill member is assured to not called concurrently with stop/updateParams) - The SkillMemory core segment for skill events uses an internal map for skills. When a provider is removed, a member will be erased from the map non locked. This may cause a segfault (however, the map is not used otherwise ATM, so for now it is fine)
Tested the GUI using ChainingSkill, ChainingAsyncSkill, InstantKillSkill, RandomChainingSkill which all call a lot of subskills (which itself may call subskills) syncronically and asynchonically. With the fixes of this branch, my GUI did not freeze anymore
PS: The GUI did not deadlock (thanks to @meixner as he added timeouts to the ice calls). However, when using the stopAll button, the GUI first tries to get all active executions from the memory (timeout 10s). If this fails, the GUI tries to stop all skills that it thinks that are running (cached from last update). For each skill, it invests max 5s to stop the skill. The stop should be much faster, but if there is a deadlock inbetween, the ice call will wait until timeout..
--> This means that for e.g. three skills that are active (in reality and in GUI cache) the GUI freezes for 25s (10s + 3*5s) if the stop call deadlocks. The more skills are active and cached, the more the GUI freezes. This may seem like a deadlock of the GUI but its not.
Since there was a bug (stopAsync was internally using stop (without Async)) the GUI waited a lot. This should also be fixed.