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).
|
|
|
|
|
|
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.
|
|
|