Messages in this thread | | | Subject | Re: [RFC] /dev/itimer | From | Nicholas Miell <> | Date | Fri, 28 Jul 2006 15:33:35 -0700 |
| |
On Fri, 2006-07-28 at 23:59 +0200, Edgar Toernig wrote: > Hi, > > this is a simple driver which provides interval timers via > file descriptors. > > Everytime I have to write code to do something at regular > intervals I face the problem that the time routines on Unix > are pretty archaic. Only a single process wide timer which > notifies via signals. The single timer asks for a dedicated > roll-your-own timer infrastructur, usually implemented via > a lot of gettimeofday calls and appropriate select timeouts. > But even if the single timer is enough, the delivery via > signals is error prone and breaks a lot of (i.e. library) > code, especially when the timer rate is high. One common > work around is forking a separate task which gets the signals > and a pipe to notify the main process which may select/poll > the other and of the pipe. But this is pretty heavy-weight > and not easy to get right either. Recently, people started > to use the real time clock driver (/dev/rtc) to get an fd > to sleep on. But this is even worse as there's (usually) > only a single one in the whole system and you have to decide > whether i.e. mplayer, artsd, timidity, or vdr gets it.
Pretty much everything in this paragraph is wrong, except for the part about the difficulty of making a single unified event loop and the resulting pipe hack that everybody uses to get around that.
Solaris lets you specify SIGEV_PORT in your struct sigevent which then queues timer completions (or anything else that takes a struct sigevent, like POSIX AIO) to a port and then all types of queued events (including fd polling and user generated events) can be waited on and fetched with a single function call.
Something similar could probably worked up in Linux which queues timer completions to an AIO context.
You might also want to look into the event channel / kevent discussion that's currently in progress.
-- Nicholas Miell <nmiell@comcast.net>
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |