Use proper timers in sleepAsync.

[dom96]

I'm surprised this wasn't done before. This should fix all problems associated with sleepAsync and high CPU usage.

[Araq]

Unfortunately that means async timers consume a file handle. This means for an HTTP connection you use 2 FDs where previously only 1 was required.

[dom96]

Yes, but this is a worthy trade-off.

[yglukhov]

This may be only useful for user-implemented runloops. Otherwise it's extremely harmful, and a showstopper for high load servers.

EDIT: Not high load servers, but the code making heavy use of sleepAsync.

[yglukhov]

I'd suggest making this a default (but configurable) option of the dispatcher.

[dom96]

For servers where this is a bottleneck I think that the developers would be better off implementing their own timing functionality. This change removes a lot of relatively complex code and I would prefer to simply remove it rather than keep it as an option.

[yglukhov]

"implementing their own" mindset doesn't play well with code reuse. E.g. I've implemented my own timers. Now I can't use third-party libs using sleepAsync.

[dom96]

Can you give a real-world example where these pseudo-timers would be necessary and the new timers would be a big problem?

[Araq]

@dom96 please add timer support to your httpbeast library and measure both the old timers and your patch.

[dom96]

@Araq The only thing I would use timers for in httpbeast is to refresh the current server time (sadly, the HTTP spec mandates that it is sent with each request...). I'm already using the OS timers for that. I can change it to use sleepAsync pre-this-PR if that's what you mean?

[Araq]

Huh? Every HTTP connection can time-out. Don't you need timers for that?

[dom96]

Huh? Every HTTP connection can time-out. Don't you need timers for that?

Nope. Although I suppose I should add those, ugh.

[yglukhov]

Let's say there's a high load HTTP server that proxies a request to another server (not necessarily HTTP), and has to return a timeout error page in case of timeout. Likely it will use asyncSleep per every request. asyncSleep consuming an FD will effectively reduce the number of concurrently handled connections by factor of 2. Not to mention that your asyncSleep introduces a syscall, which is not performance friendly.