Re: [AD] WIP 4.1.15 and CVS freeze

[Elias Pschernig <elias@xxxxxxxxxx>]

On Sun, 2004-07-25 at 17:21 -0700, Chris wrote:
> Elias Pschernig wrote:
> > The attached patch is the same as the last, but I added in the
> > YIELD_TIME constant, adjusted the GUI and examples to use it, and
> > deprecated yield_timeslice.
> 
> I only looked through the patch without applying/testing it, but I think 
> I spotted a couple problems. One:
> 
>          time = clock() + MIN(time * CLOCKS_PER_SEC / 1000, 2);
>          do {
>   +         system_driver->yield_timeslice();
>          } while (clock() < (clock_t)time);
> 
> This will cause problems. Remember, clock() runs on the process's time, 
> so if yield_timeslice succeeds in actually yielding, the clock time will 
> be thrown off. Unfortunately, there's not much you can do other than 
> return it to being a busy-wait loop until we implement a proper, 
> OS-independant time counter.
> 

Yes, but it is the rest implementation in the case there's no timer
driver, so it will rarely be used anyway, and when it is, yielding does
seem to make sense. And if you look at the old rest(), it already is
done that way in the case there is a timer - I just copied it from 2
lines above. (And I just modified the patch to check if system_driver-
>yield_timeslice is NULL, that really was missing.)

> Also, I just noticed the way you're yielding with rest(YIELD_TIME) is 
> wrong. YIELD_TIME is defined to be 10 or 30 on some platforms, however, 
> this is the /approximate/ time of the timeslice. It could end up 

It is the time found by user reports so CPU is dropped. rest(1)
apparently will make the program still use 100% CPU on these platforms.
I'm not sure what to do about it - it's one of the reasons we changed
the behavior of yield_timeslice last time actually - these 3 platforms
always had yield_timelisce wait for that long times. Not because it is
the timeslice value (not sure there are even fixed timeslices there) -
it's an experimental value needed to drop CPU.

> returning a millisecond or two before this, in which case the wait time 
> would be doubled since it would wait again, wouldn't it? And again, 
> yielding implies stopping *only if* something else wants the CPU, it's 
> not a forced thing. I think IDLE_TIME would be a better name for that 

Well, YIELD_TIME makes sense to me - it is the time we need to yield
until the scheduler drops CPU. If rest(1) would be enough on all
platforms, the constant could go away completely. But since I only can
test in linux, I really don't know - the current way makes it behave
like before if you replace yield_timeslice() by rest(YIELD_TIME).

About the name, IDLE_TIME could also be used I guess. Or
IDLE_MILLISECONDS. TIME_TO_DROP_CPU. TIME_TO_YIELD. REST_TIME. Well, I
still like YIELD_TIME most - since for me, rest(YIELD_TIME) means just
yielding to the scheduler - I want to drop CPU, so I yield long enough
for it to happen. In Windows/Linux just waiting any time will do that.
But it seems, not under others OSes.

> define. And if you're going for dropping CPU usage, shouldn't rest(1) be 
> sufficient on platforms that have a proper system sleep method? When we 
> were talking about timeslices being 10ms in Windows and Linux, and 30ms 
> in some other place, that's the approximate time it would take for the 

No, the 30ms aren't the timeslice AFAIK. But, I actually don't have an
explanation. I'll try and test it in BeOS if I can still get it to boot
on my old computer.

> scheduler to get back to us after something else uses the CPU. Getting 
> rescheduled and giving the CPU to the idle process (via rest(1)) should 
> be sufficient to sleep the program for the entire timeslice, however 
> long that may be. The only time rest(1) wouldn't work is if the system's 
> sleep method would busy-wait on small numbers, which AFAIK only happens 
> with nanosleep in real-time priority (and even there it only requires 
> something greater than 2).
> 

Well, with the patch, rest(YIELD_TIME) will behave exactly the same as
yield_timeslice() in 4.1.14. rest(0) will behave exactly the same as
yield_timeslice() in 4.1.13. The behavior of rest() is changed so it
does the same it always did in Windows now also in the unix timers.
Which is giving up CPU for the specified amount of ms, with the accuracy
depending on the OS, and in the order of 10 or 20 ms I'd say.

-- 
Elias Pschernig