From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.bugs Subject: bug#34763: 27.0.50; url-retrieve-synchronously misbehaves inside eldoc-documentation-function Date: Mon, 8 Apr 2019 19:42:04 +0300 Message-ID: References: <83a7i15vrk.fsf@gnu.org> <787f765a-42f4-40d0-3b78-e751f546fe6c@yandex.ru> <831s3c3ta8.fsf@gnu.org> <8f7ae869-2e94-5535-f16f-476348036dc2@yandex.ru> <83r2bc2csd.fsf@gnu.org> <83h8c63ek1.fsf@gnu.org> <7240d82b-5919-cee8-e3bc-81be8d996400@yandex.ru> <83pnqsyw68.fsf@gnu.org> <83pnq1diqk.fsf@gnu.org> <83lg0pdehd.fsf@gnu.org> <19dad181-7933-52b5-548f-08dfa48334bf@yandex.ru> <83h8bdc726.fsf@gnu.org> <5110bc00-c1e3-0fd3-2a4d-8f1293c80ca5@yandex.ru> <837ec48qxj.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="88552"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 Cc: 34763@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Apr 08 18:43:13 2019 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hDXMW-000Mub-4m for geb-bug-gnu-emacs@m.gmane.org; Mon, 08 Apr 2019 18:43:12 +0200 Original-Received: from localhost ([127.0.0.1]:56109 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hDXMV-0008JS-24 for geb-bug-gnu-emacs@m.gmane.org; Mon, 08 Apr 2019 12:43:11 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:34554) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hDXMO-0008J6-BJ for bug-gnu-emacs@gnu.org; Mon, 08 Apr 2019 12:43:05 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hDXMN-00021u-45 for bug-gnu-emacs@gnu.org; Mon, 08 Apr 2019 12:43:04 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:36609) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hDXML-00021a-Vp for bug-gnu-emacs@gnu.org; Mon, 08 Apr 2019 12:43:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1hDXML-00086P-N5 for bug-gnu-emacs@gnu.org; Mon, 08 Apr 2019 12:43:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 08 Apr 2019 16:43:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 34763 X-GNU-PR-Package: emacs Original-Received: via spool by 34763-submit@debbugs.gnu.org id=B34763.155474173731095 (code B ref 34763); Mon, 08 Apr 2019 16:43:01 +0000 Original-Received: (at 34763) by debbugs.gnu.org; 8 Apr 2019 16:42:17 +0000 Original-Received: from localhost ([127.0.0.1]:50153 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hDXLc-00085S-PQ for submit@debbugs.gnu.org; Mon, 08 Apr 2019 12:42:17 -0400 Original-Received: from mail-wm1-f45.google.com ([209.85.128.45]:39262) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hDXLb-00085F-5y for 34763@debbugs.gnu.org; Mon, 08 Apr 2019 12:42:15 -0400 Original-Received: by mail-wm1-f45.google.com with SMTP id n25so71334wmk.4 for <34763@debbugs.gnu.org>; Mon, 08 Apr 2019 09:42:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=gg8lEa4FnWnLHJqVbF3kqLD7k7UqFxxP1S48r/m+Gss=; b=kXohe3QO/1SCPCZLiKUvNhUKLK8sLLEwumZI/wFfl4Pvu7VNd1mIoTR+0/NNF2P2VL Bzbe668NryPfp0eJTYgqgy6N3C0lT1JTEIluuoP16ozGQiJRPc8Hzb31VtZnoLSIOylq +M0M7XWTHu2ZXN9LmjvLtUIMOzgA9Z/lyTYQGrGoBbl6kN6qEek3GDPJlMWYIjRd7VIi vfU96LtNPBfnykTv8b0zv1IUK+mxpLVZHi4fsYn99GFYovtZt30Y3vYzdUJJj4MN5W2U U8n3Zz/2o24gjQkeG0mWP1eR15bJWOUUVA30w2zWD0/b61kDZvb/oU3nobdwBX0cTPSg f80Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=gg8lEa4FnWnLHJqVbF3kqLD7k7UqFxxP1S48r/m+Gss=; b=pmjVE3Cy2/qTow99BwkWDr3gTX5NAlsetHXMHsAMCr6JDse4+xxMkAPopxWAJhCTGa 6FdblSOJtAjWsUHHxp1OrjKdaHufuZyYMduB+5Eu3KpALpCcQ76eX61iF86DNlLrxHTJ knhzjI347TevcDrtnqHt48QniLZ03gOAsv0seFSP3zJI/QtMIf6xa02ZcSPA3phI5gGB BCa8+kqFk7D6D0hHl878sY/Ffh5I9QuJi7stA/3bkoTZ1bj2l9pRZwvOr1t9HYSYaRuO 3BIfjxymgQ7ar/mmc79ao9wEcDcyJLE704bPexJ7/jbKq+bNn8jLjRgs9K5w7QSteTDy 4eHg== X-Gm-Message-State: APjAAAUxrvtCPMF+6b5IFnC71xqO9AuAP/FAan9nma5U7i5IViLPWWu8 dcWr8RglX40S+GML/2zIyDWXvcoR X-Google-Smtp-Source: APXvYqz6wFfaX1WidpXZ9jG16DU2KJoow57cdj4tefxgHFQx5Q5vGRPr7Jbzfs7pwgZVlFnFbVJpJg== X-Received: by 2002:a7b:c844:: with SMTP id c4mr17954954wml.108.1554741729123; Mon, 08 Apr 2019 09:42:09 -0700 (PDT) Original-Received: from [192.168.0.195] ([109.110.245.170]) by smtp.googlemail.com with ESMTPSA id r30sm96665319wrr.46.2019.04.08.09.42.05 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 08 Apr 2019 09:42:07 -0700 (PDT) In-Reply-To: <837ec48qxj.fsf@gnu.org> Content-Language: en-US X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] 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.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:157352 Archived-At: On 08.04.2019 18:20, Eli Zaretskii wrote: >> E.g. why doesn't url-http-debug also kill the process (but >> url-retrieve-synchronously does)? > > After installing the patch, I think we should indeed try adding code > to kill the process. That's why I asked you to try that manually > first: to see if doing that will have some positive effect. OK then. But if we're killing the process, should we worry about the sentinel and the filter? url-retrieve-synchronously doesn't bother to reset them, just kills the process. Speaking of, shouldn't that be enough for our scenario? >> And what happens if the function is interrupted before >> url-http-debug has had a chance to be called? > > Not sure why you are bothered by that. Why would we need to handle > this situation differently from the others? Well, if url-http-debug is never entered, its cleanup logic will never be executed. Shouldn't we consider that a problem as well? >> Or what if it's interrupted by a different signal than 'quit'? > > That's a different issue: in general Emacs retries the calls > interrupted by signals internally. I mean, like, interrupted by a different kind of error. Not a signal that's cleanly handled in Emacs's internals. >> Or what if it's interrupted by a symbol being thrown, set up by >> while-no-input? > > It shouldn't, that's what the change I proposed does, doesn't it? I mean the running code is interrupted, in general, by a symbol being thrown. That would also be the case of url-http-debug's cleanup never being run. >>> If you manually kill all processes but one, say, does the problem of >>> slower transfer go away? IOW, do we have two separate problems here >>> or just one? >> >> It kind of does. Killing all processes, by itself, doesn't change things. >> >> But if I also wait the aforementioned 10 minutes, transfers are fast >> once again (until I repeat the reproduction scenario). > > Hmmm... now I'm confused: originally you said something different > about those 10 minutes: > >> Bad: >> >> The requests still get slower after I've been typing a while, and the >> original speed is never recovered. Even after I wait 10 minutes or so. > > Now you seem to say that after 10-min wait the problems do go away? *If* I kill the running processes before doing that 10-minute wait, yes. At least that's what I meant. But, sorry to report, repeating the same couple of experiments again doesn't yield the same result (killing the processes didn't give any measurable impact compared to not killing them and simply waiting). So we seem to have two problems, yes. Simply waiting for a some amount of time tends to get the problem "unstuck", though the improvement is gradual and fairly unpredictable. > In Emacs, "continuation-passing" means setting up a process filter, > right? Sure, as one example. > And the process filter does read from the process, right? My > point was that being interruptible by C-g is implemented in the low > level code used by both accept-process-output and reading process > output that is fed to a filter. Okay. But that is referring to the code that reads the output, not whatever CPU-intensive loops can be inside the filter function, right? >> Anyway, I was referring to something else: the comment in url-http-debug >> mentions (IIUC) that the url-http package might use some CPU-intensive >> handling of the process output, url-http-debug being the sole quick >> escape hatch (by the virtue of it signaling an error). > > Wouldn't that be a bug of the code which does that processing? > Background processing shouldn't hog the CPU, because that makes Emacs > unresponsive. Well, URL is a general purpose package, not always used in the background. To make it suitable for background processing is the goal of the current bug report, isn't it? And as for "bug of the code", I'm saying that there must be some code that can hog the CPU (the comment refers to it), and we might want to handle that carefully. I wish somebody who knows URL's code could comment on that. >> And apparently it can be called called in contexts where inhibit-quit is >> non-nil, or else (eq quit-flag t) would never manage to evaluate to >> true, right? > > No, quit-flag could be non-nil because we don't magically test for it > everywhere, only in some strategic places. If your Lisp takes a long > time to get to one of those places, it might see quit-flag non-nil at > some point. I see, thank you. It probably means that seeing non-nil quit-flag is unreliable anyway, though, so doing cleanup or not depending on the value of that variable seems unwise.