[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <200611211009.17417.netdev@axxeo.de>
Date: Tue, 21 Nov 2006 10:09:15 +0100
From: Ingo Oeser <netdev@...eo.de>
To: Ulrich Drepper <drepper@...hat.com>
Cc: Jeff Garzik <jeff@...zik.org>,
Evgeniy Polyakov <johnpol@....mipt.ru>,
David Miller <davem@...emloft.net>,
Andrew Morton <akpm@...l.org>, netdev <netdev@...r.kernel.org>,
Zach Brown <zach.brown@...cle.com>,
Christoph Hellwig <hch@...radead.org>,
Chase Venters <chase.venters@...entec.com>,
Johann Borck <johann.borck@...sedata.com>,
linux-kernel@...r.kernel.org, Alexander Viro <aviro@...hat.com>
Subject: Re: [take24 0/6] kevent: Generic event handling mechanism.
Hi,
Ulrich Drepper schrieb:
> Jeff Garzik wrote:
> > I think we have lived with relative timeouts for so long, it would be
> > unusual to change now. select(2), poll(2), epoll_wait(2) all take
> > relative timeouts.
>
> I'm not talking about always using absolute timeouts.
>
> I'm saying the timeout parameter should be a struct timespec* and then
> the flags word could have a flag meaning "this is an absolute timeout".
> I.e., enable both uses,, even make relative timeouts the default.
> This is what the modern POSIX interfaces do, too, see clock_nanosleep.
I agree here. And while you are at it: Have it say "not before" vs. "not after".
<rant>
And if you call "absolute timeout" an "alarm" or "deadline" everyone will agree,
that this is useful.
Timeout means "I ran OUT of TIME to do it" and this is by definition relative
to a starting point. A "deadline" is an absolute point in (wall) time where sth.
has to be ready and an "alarm" is an absolute point in (wall) time where sth.
is triggered (e.g. a bell rings on your "ALARM clock").
I don't know which person established that non-sense nomenclature about relative
and absolute timouts.
</rant>
Regards
Ingo Oeser
-
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/
Powered by blists - more mailing lists