aros-development-team
Signal delivery fails under certain conditions
Observed Behaviour:
Task A starts a new Task B, and awaits a signal from Task B to indicate it has started, moving to the WAIT queue.
Task B is dispatched, and disables multitasking - then signals Task A to indicate it has started.
Task A is moved to the READY queue, while Task B then terminates running its finalization code. The finalizer calls RemTask on Task B passing it to Execs Housekeeper to destroy, and signals it.
At this point Task A is still present in the READY queue, awaiting to run and process the signal.
Execs Housekeeper is dispatched, cleaning up the Removed task, then switches to the next available task to run.
At this point Task A is no longer in the READY queue - and so never receives the pending signal.
To Reproduce No known way to reliable replicate on demand - however booting AROS will occasionally fail (typically in AddUSBClasses when it fails to obtain a lock already held by a hung task (which is waiting on a signal due to the described scenario).
Expected behaviour The waiting task should have been dispatched and processed the signal.
Screenshots N/A
Architecture
- Potentially all AROS architectures are affected.
Version N/A
Additional context N/A
Not sure if this is the same issue but under ApolloOS Archon Adept is stucked on a task (it’s using 2 or 3 I don’t recall) and its 100% reproducible.
