GNU bug report logs - #32452
26.1; gnutls_try_handshake maxes out cpu retrying when server is a bit busy

Previous Next

Full log

Message #29 received at 32452 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Noam Postavsky <npostavs <at> gmail.com>
Cc: 32452 <at> debbugs.gnu.org
Subject: Re: bug#32452: 26.1;
 gnutls_try_handshake maxes out cpu retrying when server is a bit busy
Date: Fri, 17 Aug 2018 15:25:31 +0300

> From: Noam Postavsky <npostavs <at> gmail.com>
> Cc: 32452 <at> debbugs.gnu.org
> Date: Fri, 17 Aug 2018 07:55:44 -0400
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> > OK, so do you understand the sequence of the events well enough to
> > describe what happens, and explain why we get so many EAGAIN errors?
> > I'm not yet sure this is bug, maybe it's just how things are in this
> > case (modulo exerting less CPU load, something that we certainly
> > should try).
> 
> I haven't really traced things through properly, but my current
> understanding/guess is that we're using non-blocking sockets even though
> we actually want blocking behaviour.  So to get the blocking behaviour
> we just spin in a loop.

In which case it's fine, we just need to do something in the loop to
yield the CPU, like some nanosleep, perhaps?  And maybe enlarge the
sleep period as time goes on?

> > Also, does this happen with every server, or just with some?
> 
> debbugs.gnu.org seems to be the most extreme case (at the moment), with
> other servers I see only about a hundred "Resource temporarily
> unavailable" messages (I'm noticing this now because I switched on
> gnutls-log-level, but it's not enough to cause a noticable CPU spike).

debbugs is terribly slow in a browser as well, right now.  But
hundreds of attempts sounds excessive to me.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.