On 04.08.2005 [20:59:50 +0200], Roman Zippel wrote: > Hi, > > On Thu, 4 Aug 2005, Nishanth Aravamudan wrote: > > > The comment for schedule_timeout() claims: > > > > * Make the current task sleep until @timeout jiffies have > > * elapsed. > > > > Currently, it does not do so. I was simply trying to make the function > > do what it claims it does. > > What makes you think the comment is correct? This comment was added at > 2.4.3, while schedule_timeout() has this behaviour since it was added at > 2.1.127.
Fair enough. Should we change the comment? What are the expectations of programmers wrt. to this interface? > > My point was that the +1 issues (potential > > infinite timeouts) are a problem with *jiffies* not milliseconds. And > > thus need to be pushed down to the jiffies layer. I think my explanation > > was pretty clear. > > Not really, could you go into more details why it's "a problem with > *jiffies* not milliseconds"? Well, I may have phrased that wrong. It's not that milliseconds in the kernel wouldn't have the same problem -- they would/do, because they convert to jiffies eventually. This is all the same issue, as George pointed out, that itimers face. If a user requests schedule_timeout(HZ/100); which, if HZ is 1000, is 10 jiffies, yes? But, since we are between ticks, we want to actually add that request to the next interval, not to the current one. Otherwise, we do have the possibility of returning early. Currently, we require callers to add the +1 to their request, and thus they only add it to the first one. The problem with my patch which pushed it to schedule_timeout(), is that we will do +1 to every request. I'm not sure, without some sort of "persistent" timeout control structure, how we get around that, though, in the schedule_timeout() case. Does that make any more sense? Thanks Nish - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
