From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Robert Pluim Newsgroups: gmane.emacs.bugs Subject: bug#40665: 28.0.50; tls hang on local ssl Date: Wed, 22 Apr 2020 18:14:16 +0200 Message-ID: References: <86wo6fo78r.fsf@mail.3qin.us> <86ftd35930.fsf@mail.3qin.us> <86d086dkgq.fsf@mail.3qin.us> <86eeslecnf.fsf@mail.3qin.us> <86blnnebh3.fsf@mail.3qin.us> <86zhb5hecx.fsf@mail.3qin.us> <86eeshpqdb.fsf@mail.3qin.us> <86zhb5q7sw.fsf@mail.3qin.us> <86y2qorj76.fsf@mail.3qin.us> <86368w1tge.fsf@mail.3qin.us> <864ktcfpm5.fsf@mail.3qin.us> <86368wfp6d.fsf@mail.3qin.us> <86y2qniu5m.fsf@mail.3qin.us> <86wo67im9w.fsf@mail.3qin.us> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="82920"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 40665@debbugs.gnu.org To: Derek Zhou Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Apr 22 18:18:19 2020 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jRI4o-000LSJ-UU for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 22 Apr 2020 18:18:19 +0200 Original-Received: from localhost ([::1]:53870 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jRI4n-0007G9-0L for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 22 Apr 2020 12:18:18 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:58216) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jRI1g-0004Qe-AY for bug-gnu-emacs@gnu.org; Wed, 22 Apr 2020 12:15:04 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.90_1) (envelope-from ) id 1jRI1f-0000tN-JO for bug-gnu-emacs@gnu.org; Wed, 22 Apr 2020 12:15:04 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:41474) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jRI1e-0000le-V9 for bug-gnu-emacs@gnu.org; Wed, 22 Apr 2020 12:15:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1jRI1e-0005FE-8F for bug-gnu-emacs@gnu.org; Wed, 22 Apr 2020 12:15:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Robert Pluim Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 22 Apr 2020 16:15:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 40665 X-GNU-PR-Package: emacs Original-Received: via spool by 40665-submit@debbugs.gnu.org id=B40665.158757206820106 (code B ref 40665); Wed, 22 Apr 2020 16:15:02 +0000 Original-Received: (at 40665) by debbugs.gnu.org; 22 Apr 2020 16:14:28 +0000 Original-Received: from localhost ([127.0.0.1]:53020 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jRI16-0005EE-3f for submit@debbugs.gnu.org; Wed, 22 Apr 2020 12:14:28 -0400 Original-Received: from mail-wm1-f46.google.com ([209.85.128.46]:38879) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jRI13-0005Dy-Sj for 40665@debbugs.gnu.org; Wed, 22 Apr 2020 12:14:27 -0400 Original-Received: by mail-wm1-f46.google.com with SMTP id g12so3067249wmh.3 for <40665@debbugs.gnu.org>; Wed, 22 Apr 2020 09:14:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:references:date:in-reply-to:message-id :mime-version:content-transfer-encoding; bh=v9LgOUVN2Pqz56wAmhlWS624n68CK4QbmxMz9B2+i4s=; b=W7Dr1/j7KMEADku0TEA/Xy6gre95fHd8Ha44fGH8rMucrN/rSqFOEISHBsk6PLx3mV SG7kmzb0f8tXbSsvMz2EB+pEsbH3GyBGBqsJv8lhFYkN2WKOLi8YQ2u9dfSksuAkrZRH g6mjEwbY8WI8r6R2beevs8FmClbk8lcpdVs8TQeYyjIML9+gE07MksXGvWNoSoHonH2i KlLL1FSBPcbDN8/e1LhB+AdWv9sH9qFOFWfUeZKRTS7SAHFPWTnH0szeWZot+WTfMQ9w xkGUerBDvoDTQpm27Ev/ev+/HI8pX0cZEzfkzp++GQy3smogwelggvDSMLO0NO6MiC1V 4zOA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:mime-version:content-transfer-encoding; bh=v9LgOUVN2Pqz56wAmhlWS624n68CK4QbmxMz9B2+i4s=; b=icSEOeU5LfWgaqArRPKG9YgWcOHL1ZcltXq6rB5gfTYh/yutH6KaxWOfk770hELGFn jYWRlY3jYnT8m5/SpfSdFNEEE3J+43O8bHiKxLIBjkkmNqAtxDp5ztiG6mMVw1PDhN8A l4WEFRE4xdg1/yZqrjRD28EoeQC2pP2A5W+F6bZD4K6dYoW/Mg/bVdP2Gvn3lVdoy/qq 197jSpvEIuv+WnAtzVSKRBaYgZtNww5X5FZDd3OSMmY2hEvLkeWnyVsxjlZ14Tm8qjqb 2QWbI9xbX/C+vWOsNl+tNHr8i/jcROkwuvvLuTdh+rmHYNgO5I8rSSa0brzGhoXVG2zC 8FpQ== X-Gm-Message-State: AGi0Puai0OyRb3Vot4CVirrmHf4S7h+GzfvLu+zkbEVjVaZ7nNNDo+j9 qtrNq9BZDhb614now3pyxYyBzDDC X-Google-Smtp-Source: APiQypKx3xuUwoPBxNBo46gUokUuung77qcJ8u/b4v0/Sjb4Cmqox1FewUbGN1vTojoRsBaJFK1enw== X-Received: by 2002:a1c:a344:: with SMTP id m65mr11382066wme.20.1587572059357; Wed, 22 Apr 2020 09:14:19 -0700 (PDT) Original-Received: from rpluim-mac ([2a01:e34:ecfc:a860:f038:efd9:aa5f:7833]) by smtp.gmail.com with ESMTPSA id q10sm9234216wrv.95.2020.04.22.09.14.17 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 22 Apr 2020 09:14:18 -0700 (PDT) In-Reply-To: <86wo67im9w.fsf@mail.3qin.us> (Derek Zhou's message of "Wed, 22 Apr 2020 15:16:12 +0000 (UTC)") X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-Received-From: 209.51.188.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:178804 Archived-At: >>>>> On Wed, 22 Apr 2020 15:16:12 +0000 (UTC), Derek Zhou = said: >> The reason for checking wait_proc is to allow 'accept-process-output' >> to specify that emacs should return only when there is data for that >> specific process, with your patch it can return if there is any data >> in the TLS buffers for any connection, but none for wait_proc. That >> would make 'accept-process-output' return earlier than expected, or >> even return for the case where the timeout is infinite. >>=20 >> A quick survey of the emacs sources shows almost every call to >> 'accept-process-output' passes in wait_proc, so I think that your >> change as it stands is too risky. With a check for wait_proc it might >> be OK. >>=20 Derek> My counter argument is if we really only care about some of the = the fds Derek> but not all the fds, the proper way is to let select know by pas= sing in Derek> the proper narrower set of fds, maybe the code is already this w= ay? It is very Derek> complicated so I am not sure. I am checking only those fds that = are both Derek> 1, gnutls managed, and the 2 set in the input for readfds for the Derek> select, so I believe it is the right thing. That=CA=BCs not quite it. 'wait_reading_process_output' broadly does one of: 1. Read from some fds, give me what you have or timeout 2. Read from some fds, wait until you have something for this specific process, or timeout 3. Read *only* for this process, wait until you have something, or timeout [1] is very common, [3] is not. The case I=CA=BCm discussing is [2] (via accept-process-output), and as it stands you've transformed it into a form of [1] (and yes, in [3] the select is only done for the fd for a specific process). Derek> Another way is to still do a zero timeout select, and merge the = gnutls Derek> ready set with the select ready set. It is more intrusive but pr= obably Derek> closer to the original intent of the code. I can write the path = that way Derek> if you want. >>=20 >> I don=CA=BCt think we always do a zero timeout select. This sounds e= ven >> riskier. Derek> I am proposing doing a zero timeout select ONLY if the gnutls bu= ffer Derek> check already flags some of the channels. This way we can also s= elect those Derek> FDs that are not gnutls managed, but already ready to read at th= e same Derek> moment. It is closer to the origin intention of the select, I Derek> believe. If the gnutls buffer check does not flag anything of ca= use we do Derek> the select with timeout exactly as before. My current patch may = leave Derek> out some ready fd unchecked until the next round. OK, that does make sense, and might even be more correct, but it=CA=BCs a bigger change. You'll need more than just me to agree with it. Robert