Commit graph

7 commits

Author SHA1 Message Date
Ondrej Zajicek (work) 7be3af7fa6 Rate-limit scheduling of work-events
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).
2021-03-12 15:35:56 +01:00
Ondrej Zajicek (work) 961671c0f5 Lib: Add and use ev_new_init() 2018-10-01 15:55:23 +02:00
Ondrej Zajicek 6f8bbaa10b Fininshing integrated OSPF. 2014-11-03 10:42:55 +01:00
Martin Mares 8f6accb5bb Event handlers no longer return re-queue flag. Instead of using it, just
call ev_schedule() on the same handler which should work perfectly now.
2000-04-27 22:28:49 +00:00
Martin Mares 84a7d7f77c ev_run() now returns whether the event has been requeued or not.
ev_run_list() now returns number of events which remain in the list.
1999-11-17 12:01:11 +00:00
Martin Mares 0d70292d88 Events now return a value. If it's non-zero, the event is re-queued
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.
1999-10-29 12:08:49 +00:00
Martin Mares 3b15402fd4 Grrr, forgot to commit the event routines themselves :| 1999-02-11 22:18:36 +00:00