Original value was too small once both ESP8266 driver and
asynchronous DNS started to use shared event queue. An assumption is
made that once shared event queue is taken into use there are going to
be multiple users instead of one, for which the original value would
have been sufficient.
ESP8266 driver started to use global event queue to handle some AT
parsing and call Socket::sigio() events. It turned out that when
running DNS tests, or Pelion Client, the stack space (1kB) is not
enough for the purpose.
Therefore we propose that this is raised to 2kB, as the assumption
is that event loop should allow as equivalently complex code than
any other threads.
In Mbed OS, the default Thread stack size is 4kB, but we assume 2kB
to be enough for non-blocking event purposes.
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.
Event queue was using its own Timer or LowPowerTimer objects to derive
millisecond tick counts. This is unnecessary in RTOS builds, where the
RTOS is maintaining a tick count.
It also makes more sense to use the actual RTOS tick count, as the
values are being used to compute tick timeouts for RTOS calls. Computing
these RTOS tick delays with a separate timer could conceivably lead to
rounding errors.
Fixes: #5378
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)) {