[Twisted-Python] Scalability of timers

[Tobias Oberstein]

>There is only one select() call (or whatever) at any given time, regardless of how many timers.

Yes, I do understand this.

>Syscalls are thus O(1). Timers are stored in sorted order. When event loop wakes up it removes timers that have been reached, which is fast because they're sorted so when you hit one that is still in future you can stop. So that's pretty scalable.

syscalls are O(1). But the constant is non zero. A syscall is still quite expensive. try doing 1 mio. syscalls/sec on any x86 box (Linux, BSD, whatever). DEC Alphas and Itanium might be able to do more, but the context switching overhead of x86 architecture is "huge".

But I feel I failed in formulating what I am asking.

Could you please correct where my thinking below goes wrong?

Let's say I issue 1 mio. timers with expirary times t0, t0+1us, t0+2us, .., t0+1s

That is 1 mio. timers expiring in 1us pitch within 1s.

That will mean 1 mio. select() syscalls done in 1s each with timeout set to 1us

Since it's unlikely that a box supports a rate of 1 mio. syscalls/sec, that means a select with timeout 1us won't return after 1us, but >1us. Twisted will process all timers that have expired in the meantime. But there is no way of letting 1 mio. timers fire in 1us pitch within 1s using a syscall.

What I am after is to explicitly _control_ the maximum syscall rate to select() - not simply max. out the box on syscall rate.

Like: limit syscall rate to select() at 1000Hz - regardless how many timers I issue per second.

In above example, with syscall max set to 1000Hz, each time select() returns 1000 timers would have expired. That's fine. That's what I want.

How can I do that?

Thanks!
Tobias