From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Richard Stallman Newsgroups: gmane.emacs.devel Subject: Re: url-retrieve-synchronously randomly fails on https URLs (patch included) Date: Mon, 29 Oct 2007 05:22:26 -0400 Message-ID: References: <20071027104716.E9BA773545@tanja.localdomain> <1c34ba170710280540g5b2a9983o33abfcba2843d95@mail.gmail.com> Reply-To: rms@gnu.org NNTP-Posting-Host: lo.gmane.org Content-Type: text/plain; charset=ISO-8859-15 X-Trace: ger.gmane.org 1193650194 15169 80.91.229.12 (29 Oct 2007 09:29:54 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 29 Oct 2007 09:29:54 +0000 (UTC) Cc: emacs-devel@gnu.org To: "Riccardo Murri" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Oct 29 10:29:56 2007 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1ImQwV-0007Ee-Pz for ged-emacs-devel@m.gmane.org; Mon, 29 Oct 2007 10:29:56 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1ImQwM-0003h8-DL for ged-emacs-devel@m.gmane.org; Mon, 29 Oct 2007 05:29:46 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1ImQpK-00076Z-HL for emacs-devel@gnu.org; Mon, 29 Oct 2007 05:22:30 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1ImQpI-00074M-D3 for emacs-devel@gnu.org; Mon, 29 Oct 2007 05:22:29 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1ImQpH-00073v-U2 for emacs-devel@gnu.org; Mon, 29 Oct 2007 05:22:28 -0400 Original-Received: from fencepost.gnu.org ([140.186.70.10]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1ImQpG-0007rh-UJ for emacs-devel@gnu.org; Mon, 29 Oct 2007 05:22:27 -0400 Original-Received: from rms by fencepost.gnu.org with local (Exim 4.60) (envelope-from ) id 1ImQpG-0001Wa-LS; Mon, 29 Oct 2007 05:22:26 -0400 In-reply-to: <1c34ba170710280540g5b2a9983o33abfcba2843d95@mail.gmail.com> (riccardo.murri@gmail.com) X-detected-kernel: by monty-python.gnu.org: Linux 2.6, seldom 2.4 (older, 4) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:82054 Archived-At: Unless I got it all wrong, this is much more complicated than the original three-liner; I wonder if it is worth going this way instead of a very simple patch that could still be buggy on rare occasions. It is a bad thing for software to be unreliable. We should write it so that it works every time, not just 99.9% of the time. It is worth paying this small complexity to make it work right. Besides, the code can be simpler. + ;; advance point to after all informational messages that + ;; `openssl s_client' and `gnutls' print + (lexical-let ((attempts tls-end-of-info-match-attempts) + (start-of-data nil)) Why not ordinary let? + (not (= 0 (if (> attempts 0) (decf attempts) -1))) I think there should not be a limit -- it should just keep looping until it finds what it is looking for. + (unless (accept-process-output process 1) + (sit-for 1))) I think there is no need for sit-for. accept-process-output will wait. + (warn + "`open-tls-stream': Could not match `tls-end-of-info' regexp in %d attempts." + tls-end-of-info-match-attempts))) If you get rid of the counter, you won't need this either.