Re: [PATCH] 'select' failure or signal should not update timeout

[Jamie Lokier <lk@tantalophile.demon.co.uk>]

Eric W. Biederman wrote:
> torvalds@transmeta.com (Linus Torvalds) writes:
> > A _useful_ interface would be to say "I want to sleep to at most time X"
> > or "to at least time X".  Those are unambiguous things to say, and are
> > not open to interpretation.
> 
> Sleeping until at most time X is only useful if the kernel can actually
> make a guarantee like that.  If you are doing hard real time fine, otherwise
> that doesn't work to well.

Oh, that would definitely be useful even if it's only a "soft"
guarantee.  Especially with recent HZ changes.

Typical soft real-time code looks a bit like this pseudo-code (excuse
the bugs :-):

	void wait_until_time (const struct timeval * until)
	{
		struct timeval now, timeout;
		while (1) {
		        gettimeofday (&now, 0);
		        timeout.tv_sec = until->tv_sec - now.tv_sec;
			timeout.tv_usec = until->tv_usec - now.tv_usec;
			if (timeout.tv_usec < 0) {
				timeout.tv_usec += 1000000;
				timeout.tv_sec -= 1;
			}
			if (timeout.tv_sec < 0)
				break;		/* Finished! */
			timeout.tv_usec -= SCHEDULER_GRANULARITY;
			if (timeout.tv_usec < 0) {
				timeout.tv_usec += 1000000;
				timeout.tv_sec -= 1;
			}
			/* Busy wait if within scheduler granularity. */
			if (timeout.tv_sec > 0) {
				select (0, 0, 0, &timeout);
			}
		}
	}

Note that SCHEDULER_GRANULARITY is an architecure-specific and
OS-specific constant that has to be determined somehow.

The select() call in the above code is one that would, ideally, be "wait
until at most TIME" even if that is limited by the granularity of
scheduler timeouts.  The scheduler may not be able to _guarantee_ to
schedule the process before TIME (fair enough, that's why we call it
soft real-time), but at least the tick calculations etc. in the kernel
would be rounded down, rather than up.

-- Jamie