Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

"A sleep(1) is put into all SSL_read() and SSL_write() calls..."

bugs.python.org

Post reply on HN
Print view View original

21–30 of 52 posts

Re: "A sleep(1) is put into all SSL_read() and SSL_write() calls..."

#21

Post by mustpax »

igravious wrote: post #18
typedef_void wrote: post #5

Earlier quoted context omitted.

is sleep(1) noisy? if so, it might be vs timing attacks

Excuse my ignorance: what do you mean by noisy?

Noisy means there is a lot of variance in the actual time the process spends sleeping. When you say sleep(1) most OSes interpret that as saying, sleep as short as you can. Based on the scheduler internals, that can vary a lot.

Re: "A sleep(1) is put into all SSL_read() and SSL_write() calls..."

#22

Post by timf »

A second long sleep on every read or write? If this was actually happening, it sounds like it could create unheard of performance issues for any significant transfer.

Or was this not noticed because all the major frameworks like cherrypy and twisted are still using the pyopenssl wrapper?

Is there any evidence that this bugfix actually changes the performance?

Re: "A sleep(1) is put into all SSL_read() and SSL_write() calls..."

#23

Post by MrRage »

timf wrote: post #22

A second long sleep on every read or write? If this was actually happening, it sounds like it could create unheard of performance issues for any significant transfer. Or was this not noticed because all the major frameworks like cherrypy and twisted are still using the pyopenssl wrapper? Is there any evidence that this bugfix actually changes the performance?

Don't you mean a millisecond long sleep? I never saw a sleep function that interpreted its parameter as seconds. Edit: Well, now I know better.

Re: "A sleep(1) is put into all SSL_read() and SSL_write() calls..."

#24

Post by jamesseda »

ars wrote: post #20
jamesseda wrote: post #19

Earlier quoted context omitted.

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.

Uhhh. I think you need to study this topic some more. > 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. A block will end when the nic can handle more data. You can't just wait a second and assume the nic can handle the data. That's where the "unreliable" part comes in. You assume it can handle the data, but you are not chec…

cool, I'll check the nic status before sending if I ever want to maximize throughput. But I'll probably rewrite it in C at that point too.

Re: "A sleep(1) is put into all SSL_read() and SSL_write() calls..."

#25

Post by kingkilr »

MrRage wrote: post #23
timf wrote: post #22

A second long sleep on every read or write? If this was actually happening, it sounds like it could create unheard of performance issues for any significant transfer. Or was this not noticed because all the major frameworks like cherrypy and twisted are still using the pyopenssl wrapper? Is there any evidence that this bugfix actually changes the performance?

Don't you mean a millisecond long sleep? I never saw a sleep function that interpreted its parameter as seconds. Edit: Well, now I know better.

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

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

Re: "A sleep(1) is put into all SSL_read() and SSL_write() calls..."

#26

Post by dmm »

MrRage wrote: post #23
timf wrote: post #22

A second long sleep on every read or write? If this was actually happening, it sounds like it could create unheard of performance issues for any significant transfer. Or was this not noticed because all the major frameworks like cherrypy and twisted are still using the pyopenssl wrapper? Is there any evidence that this bugfix actually changes the performance?

Don't you mean a millisecond long sleep? I never saw a sleep function that interpreted its parameter as seconds. Edit: Well, now I know better.

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

Re: "A sleep(1) is put into all SSL_read() and SSL_write() calls..."

#27

Post by timf »

kingkilr wrote: post #25
MrRage wrote: post #23

Earlier quoted context omitted.

Don't you mean a millisecond long sleep? I never saw a sleep function that interpreted its parameter as seconds. Edit: Well, now I know better.

It does on Linux, from `man 3 sleep`: http://paste.pocoo.org/show/229678/

This is what I was going on, I checked that man page, incredulously...

Re: "A sleep(1) is put into all SSL_read() and SSL_write() calls..."

#28

Post by sprout »

fourneau wrote: post #13
kqr2 wrote: post #7

It looks like someone forgot to remove the "speed-up loop". http://thedailywtf.com/Articles/The-Speedup-Loop.aspx

That's both hilarious and frightening all at once. Luckily static analysis tools catch that kind of stuff very easily now...

Not in the cloud they don't.

Re: "A sleep(1) is put into all SSL_read() and SSL_write() calls..."

#30

Post by dredge »

As the bug report mentions, the sleep(1) call appears to be wrapped in a #define that (I assume) won't be active in normal OpenSSL builds. At least in v0.9.8o (the only one I checked) the only references I see are:

ssl/s2_pkt.c:

    #ifdef PKT_DEBUG
        if (s->debug & 0x01) sleep(1);
    #endif
There are two references like that to PKT_DEBUG (read and write); the only other is:

ssl/ssl_locl.h:

    /*#define PKT_DEBUG 1   */
I suspect this is a non-issue. Interesting though.
Post reply on HN