Thanks for the pointer
Posted Oct 4, 2007 1:50 UTC (Thu) by filker0
In reply to: Error conditions, other considerations
Parent article: The new timerfd() API
Thanks for the response. I'd not seen the manpage before. I'm not on the kernel mailing list due
to lack of time right now.
I did some development on an embedded kernel some years ago that had a feature similar to
these timers. They could be annonymous (not visible to other tasks) or named. Named timers
persisted from creation to the end of time (well, until you shut down or reset the box) -- it was
an embedded system, we didn't need to delete them. A named timer could be created and set,
then closed. Any task could open the timer and do a blocking read, which would block the task
until it expired, or a non-blocking read which would return the number of days/hours/minutes/
seconds/ticks until the next expiration, additional reads would return the next expiration after
that, and so on. A blocked task could be awaken from a read by an AST (asynchronous system
trap, this was more RSX than Unix like). You set the timer by writing to it (it was a binary
structure that contained timer information). Timers could be set using relative or absolute time,
and could have single or repeating events, and you could have up to 8 events of any type queued
up in a timer. Each event structure also had a chain of completion and cancellation callbacks
that could, in theory, be arbitrarily long. Since it was an embedded system, we provided no real
protection on these things, and if you scheduled a callback from your task and then terminated,
the callback would still get called unless you cancelled it before termination.
It was a very useful and somewhat nifty system for inter-task synchronization in a mostly
asynchronous application (a high end video terminal).
Anonymous timers were pretty much the same except that they were destroyed when your task
exited and were not visible to other tasks. We didn't have fork(), nor exec() as Unix/Linux has
them, so nothing ever got inherited. All the code on the system was always there (we ran out of
ROM), and a task was just a thread of execution that was started with a system call.
Anyway, thanks again for the response.
to post comments)