GNU bug report logs -
#32452
26.1; gnutls_try_handshake maxes out cpu retrying when server is a bit busy
Previous Next
Reported by: Noam Postavsky <npostavs <at> gmail.com>
Date: Thu, 16 Aug 2018 12:14:01 UTC
Severity: minor
Tags: moreinfo
Found in version 26.1
Fixed in version 29.1
Done: Lars Ingebrigtsen <larsi <at> gnus.org>
Bug is archived. No further changes may be made.
Full log
Message #103 received at 32452 <at> debbugs.gnu.org (full text, mbox):
> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: eggert <at> cs.ucla.edu, bug-gnulib <at> gnu.org, npostavs <at> gmail.com,
> 32452 <at> debbugs.gnu.org
> Date: Mon, 28 Feb 2022 13:35:47 +0100
>
> Lars Ingebrigtsen <larsi <at> gnus.org> writes:
>
> > grep --color=auto -nH --null -e rpl_nanosleep `find . -type f`
> > ./lib/time.h647:# define nanosleep rpl_nanosleep
> > ./lib/time.in.h140:# define nanosleep rpl_nanosleep
> >
> > And that's it.
>
> The header file continues:
>
> # if 0
> # if GNULIB_PORTCHECK
> # if !(defined __cplusplus && defined GNULIB_NAMESPACE)
> # define nanosleep rpl_nanosleep
> # endif
> _GL_FUNCDECL_RPL (nanosleep, int,
> (struct timespec const *__rqtp, struct timespec *__rmtp)
> _GL_ARG_NONNULL ((1)));
> _GL_CXXALIAS_RPL (nanosleep, int,
> (struct timespec const *__rqtp, struct timespec *__rmtp));
My guess is that _GL_FUNCDECL_RPL should produce a rpl_nanosleep.
But I'm sure Gnulib folks will see the reason much faster than my
guesses.
This bug report was last modified 3 years and 117 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.