linux-kernel - Re: [RFC] /dev/itimer

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <1154126015.2451.13.camel@entropy>
Date:	Fri, 28 Jul 2006 15:33:35 -0700
From:	Nicholas Miell <nmiell@...cast.net>
To:	Edgar Toernig <froese@....de>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: [RFC] /dev/itimer

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@...cast.net>

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/