| Age | Commit message (Collapse) | Author |
|---|
|
|
|
In general, events are code handling some some condition, which is
scheduled when such condition happened and executed independently from
I/O loop. Work-events are a subgroup of events that are scheduled
repeatedly until some (often significant) work is done (e.g. feeding
routes to protocol). All scheduled events are executed during each
I/O loop iteration.
Separate work-events from regular events to a separate queue and
rate limit their execution to a fixed number per I/O loop iteration.
That should prevent excess latency when many work-events are
scheduled at one time (e.g. simultaneous reload of many BGP sessions).
|
|
|
|
|
|
|
|
|
|
This also fixes bug that timer->recurrent was not cleared
in tm_new() and unexpected recurrence of startup timer
in BGP confused state machine and caused crash.
|
|
WALK_LIST_DELSAFE (in ev_run_list) is not safe with regard
to deletion of next node. When some events are rescheduled
during event execution, it may lead to deletion of next
node and some events are skipped. Such skipped nodes remain
in temporary list on stack and the last of them contains
'next' pointer to stack area. When this event is later
scheduled, it damages stack area trying to remove it from
the list, which leads to random crashes with funny
backtraces :-) .
|
|
|
|
|
|
call ev_schedule() on the same handler which should work perfectly now.
|
|
|
|
ev_run_list() now returns number of events which remain in the list.
|
|
for processing in next event cycle. This can be used to prevent background
actions (hint: user commands) from hogging the CPU for too long time.
|
|
should work now. Initial feeding of protocols by interfaces/routes is
done from the event queue to prevent unwanted recursion.
|
|
|
