Lex,

Just a correction:

> Scott Crosby wrote:
> > The variable read may, but the function call overhead 
> > doesn't.. Yes, it makes it about 10x cheaper. But the correct
> > solution is to *not* read the clock 40,000 times a second. 
> > Andreas Raab's patch (which I referenced) reduces this. If
> > you don't read it 40,000 times a second, you're not
> > invoking 40,000 or more functions/second, and its going to 
> > be better.
> 
> It's probably more than 10x faster -- on x86, a system call is on the
> order of 1000 cycles!  Also, it doesn't have to be a real 
> function call -- it can be a macro, and thus turn into a simple
> read from a global variable.
> 
> 
> Anyway, sure, both patches sound useful.  There's no need to check the
> time on ultra-fast primitives, and some platforms won't be able to
> implement such a speedy time check, anyway.  

This is not true. The patch reduced the number of calls without
introducing any extra support functions. Every platform which has a
timer call, no matter how expensive, can implement it (and a timer call
is required anyways). It's major advantage is on platforms where the
timer calls are slow - e.g., when there's no ioLowResMSecs
#primitiveResponse will call the expensive timer at least twice per
primitive invokation if there's some active delay.

The threaded solution is nicer but try to implement it on a platform
which either has no threads or where threads are still scheduled
non-preemptively. I would've had this problem on the PS2 port - the
existing threads were not preemptive (for a reason) and I really didn't
want to go into the details of PS2 interrupt programming (all the
examples had Japanese comments ;-)

Cheers,
  - Andreas