"A sleep(1) is put into all SSL_read() and SSL_write() calls..." (opens in new tab)

Sleep(1) is very noisy on Windows machines. The time slice given by default is ~15-20ms [1], and calling Sleep(<15) relinquishes the rest of the time slice. Windows has a multimedia API that can be used to get intervals down to 1ms, but it requires system calls that increase your system load. So you usually just need to use proper synchronization anyways, which is what the Python guys should have done :)

This crummy Sleep() implementation has some nice effects on programmers. Those who like to solve problems with lots of copy/paste code are forced to think about using proper synchronization primitives when running high resolution loops that wait for events, or their code just won't run very fast.

[1] http://social.msdn.microsoft.com/forums/en-US/clr/thread/fac...

This has nothing to do with timing attacks and would do nothing to defend against them. Read 'daeken's comment below, though.

Excuse my ignorance: what do you mean by noisy?

Sleep is noisy.

When you do sleep, depending on the hardware, the OS, the configuration, the kernel flags, etc. the minimum you actually get is around 38.

But that varies.

on second thought, my comment makes little sense,

if they wanted noisy sleep, it should be something like

sleep(func(rand()))

Additionally I think you'd be hard pressed to find a modern compiler (for some loose definition of modern) which would not optimize that loop away.

Not in the cloud they don't.

Both the POSIX sleep() program and the sleep(unsigned int seconds) function in unistd.h interpret the argument as seconds.

It does on Linux, from `man 3 sleep`:

http://paste.pocoo.org/show/229678/

it is actually more reliable to sleep than to block. by definition blocking is unreliable because you don't know exactly when it will unblock. You do know when a sleep will end though. I also want a variable delay between writes.