diff options
| author | Kimplul <kimi.h.kuparinen@gmail.com> | 2022-05-22 23:35:02 +0300 |
|---|---|---|
| committer | Kimplul <kimi.h.kuparinen@gmail.com> | 2022-05-22 23:35:02 +0300 |
| commit | 72df0de8cb579fd96449d19eb57fc71335907a19 (patch) | |
| tree | 6a0a24478fe95f009619787afd24ddfe5df8cfd7 /common/timer.c | |
| parent | d99be9e2912e0726ab779053b43a89e3b9e21490 (diff) | |
| download | kmi-72df0de8cb579fd96449d19eb57fc71335907a19.tar.gz kmi-72df0de8cb579fd96449d19eb57fc71335907a19.zip | |
add @file info to all files
+ Next step, start documenting contents of each file.
Diffstat (limited to 'common/timer.c')
| -rw-r--r-- | common/timer.c | 14 |
1 files changed, 14 insertions, 0 deletions
diff --git a/common/timer.c b/common/timer.c index 0442c44..0a11dc8 100644 --- a/common/timer.c +++ b/common/timer.c @@ -1,3 +1,17 @@ +/** + * @file timer.c + * Timer handling implementation. Currently we only expect an architecture to + * support a single timer per core. + * + * By keeping all timers in a binary search + * tree ordered by time, we can just set the single timer to interrupt us when + * the next timer is due and with thread info call the thread that set the + * timer. From what I can tell, this is largely what Linux does. + * + * \todo Figure out if there are any advantages to having multiple concurrent + * timers. + */ + #include <apos/sp_tree.h> #include <apos/string.h> #include <apos/nodes.h> |
