As for your other comments, Marc-Andre:

> * Please check whether you can move these variable declarations inside
> the main loop function (as statics):
> [snip]

They are used in other functions than in the main loop, so it's not possible.

> * Please add the fallback solutions from the time module in case 
> gettimeofday() is not available. You cannot assume that "all modern
> POSIX systems" implement that API - it was introduced in POSIX 2001
> and Python 2.x still supports OSes that were released prior to that
> year.

I didn't know about that. In the context of py3k, I'm not sure it is really annoying, but you're right that for 2.x a fallback might be needed.

By the way, the new GIL only works with POSIX and Windows NT threading APIs. Perhaps it can't be backported at all to 2.x, given that 2.x supports more threading APIs than py3k does?

> I haven't looked at the timing details of the implementation, but
> please make sure that it works even if the clock interval is a few ms

Well, since it works under Windows (I don't have any really reliable benchmarks, since I've tested under a VM which is not an ideal condition), I assume it's robust against poor timing precisions.
(under Windows, WaitForMultipleObjects() is used which according to the MSDN docs has worse than microsecond precision)

But, yes, testing would be welcome on such platforms.