On Mon, Apr 28, 2008 at 3:14 PM, Anupam Kapoor <anupam.kapoor@xxxxxxxxx> wrote:
> Michael Kerrisk <mtk> wrote:
> On Mon, Apr 28, 2008 at 7:12 AM, Anupam Kapoor <anupam.kapoor@xxxxxxxxx> wrote:
> ,----
> | > one simple question though: should'nt it be possible to simulate the
> | > interface provided by timerfd using a combination of signalfd +
> | > getitimer ?
> |
> | Each timer delivers its notification on a different file descriptor.
> | We can't do that using signalfd + a traditional timer mechanism. (By
> | the way setitimer wouldn't come close -- you can only have one
> | wall-clock timer set via that API -- POSIX timers allow multiple
> | timers...)
> `----
> yes {get,set}itimer provide only a single timer / process. posix timers
> aka timer_create and friends do allow for multiple timers /
> process.
>
> but, with posix-timers too, it seems that the number is limited by the
> current number of outstanding signals for a process (this seems to be
> RLIMIT_SIGPENDING which is '11' on x86, after a quick glance, so i might
> be wrong).
There's more subtlety involved: multiple tiemr exprirations are
colalesced if the program doesn't accept them. So if, for example,
signals are blocked and then unlbocked, then the next handler
invocation (or call to sigwaitinfo()) will return just a single
signal. But then tiemr_gettoverrun() can be used to check how many
extra expirations there were. So the pending signal limit doesn't
really matter.
> i guess, with the new timer api, this would not be an issue (except
> ofcourse a limit on max-open-fd's / process which can always be
> changed) ?
Well, a read() from a timerfd simply returns however many expirations
occurred. So there is no practical limit.
Cheers,
Michael
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Found a bug? http://www.kernel.org/doc/man-pages/reporting_bugs.html
--
To unsubscribe from this list: send an email with
"unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx
Please read the FAQ at http://kernelnewbies.org/FAQ
