In `equeue_destroy` the external loop was for main events linked
list and internal loop for siblings.
Siblings start was not initialized correctly for each main link
When adding sibling at the head of linked list, the head if pointing
to something in linked list was not updated, hence a loop was formed
in linked list
Element0 - First addition to linked list
Element1 - Has higher delay hence added to back
0 ->(next) 1
Element2 - Delay is same as Element0, hence should be sibling of 0
Shall be added at head
Expected:
2 ------------->(next) 1
|(sibling)
0
Bug: (Resolved with this)
2 ------------->(next) 1
|(sibling)
0 ------------->(next) 1
If we add more elements and next pointer of sibling is updated, old
references will cause issues
Element3 added
Expected:
2 ------------->(next) 3 ------------->(next) 1
|(sibling)
0
Bug: (Resolved with this)
2 ------------->(next) 3 ------------->(next) 1
|(sibling)
0 ------------->(next) 1
***Both siblings here point to different next***
Issue was seen with below example
EventQueue q1;
EventQueue q2;
void main() {
while( true ) {
q1.chain( &q2 ); // Chain q2 to q1
q1.chain( NULL ); // Remove chain from q1
//This second step should free the memory from the chained q2 event.
}
}
Memory allocated from q1 slab was freed for q2, which will result in
memory leak.
If user has initiated a delayed event (either with call_in or call_every),
user might need to know how much time is left until the event is
due to be dispatched.
Added time_left() function can be used to get the remaining time.
Building with (GNU Tools for Arm Embedded Processors 7-2017-q4-major) 7.2.1 20170904 gives this warning
../events/equeue/equeue.c: In function 'equeue_incid':
../events/equeue/equeue.c:40:17: warning: '<<' in boolean context, did you mean '<' ? [-Wint-in-bool-context]
if (!(e->id << q->npw2)) {
The equeue_chain function is supposed to unchain the event queue
from whatever queue it is chained to when passed a null target.
Internally, this is accomplished by just calling equeue_background
with null and letting the previously registered update function
clean up the chaining.
However, equeue_chain did not appropriately check for null, causing
it to unnecessarily allocate memory and leaving the update function
in a bad state. Fixed with a simple null check.
With ARM Compiler 5.06u3, when the equeue_tickdiff function is
inlined, the compiler treats the unsigned integer subtraction
as undefined behaviour and assumes falsely the comparisons
could never be true.
The workaround is to an explicit cast, which politely reminds the
compiler to emit the correct comparison.
Added mbed-events from https://github.com/ARMMbed/mbed-events. Changes
from upstream:
- the whole code is licensed under the Apache license. Sources and
headers were updates with this information.
- removed the porting layers for Windows and FreeRTOS and the references
to these porting layers in equeue_platform.h.
- moved the TESTS directory in mbed-events to the TESTS directory of
mbed-os.