* bug#58218: 29.0.50; url-retrieve-synchronously with timeout causes process-query-on-exit
@ 2022-10-01 10:55 Phil Sainty
2022-10-01 11:44 ` Eli Zaretskii
2022-10-01 12:33 ` Lars Ingebrigtsen
0 siblings, 2 replies; 6+ messages in thread
From: Phil Sainty @ 2022-10-01 10:55 UTC (permalink / raw)
To: 58218
If you use the TIMEOUT argument to `url-retrieve-synchronously' and the
response is not obtained within that duration, then the process created
for that request causes query-on-exit behaviour. I can reproduce this
in all the Emacs builds I have, including this 29.0.50 build.
;; With a short timeout causing the request to be aborted:
(url-retrieve-synchronously "http://www.example.com" nil nil 0.01)
nil
M-x list-processes
www.example.com -- open -- -- Main (network connection to
www.example.com:80)
C-x C-c
Active processes exist; kill them and exit anyway? (yes or no)
;; With a long timeout (or a nil timeout):
(url-retrieve-synchronously "http://www.example.com" nil nil 5)
#<buffer *http www.example.com:80*>
M-x list-processes
www.example.com -- open -- -- Main (network connection to
www.example.com:80)
C-x C-c
exits without any process-related prompt
I'm not sure why the network connection remains open in either case, but
regardless of that it seems as if process-query-on-exit-flag is set if
the request times out, and cleared if it does not. The query-on-exit
case seems to me like a bug, especially when there is no obvious way to
obtain the process object and change the flag.
I found bug #34607 when searching, but I don't understand what's being
discussed there; especially the example code for this:
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=34607#22
which seems to me like it would be signalling an error when it winds
up evaluating (with-current-buffer nil ...)
-Phil
In GNU Emacs 29.0.50 (build 4, x86_64-pc-linux-gnu, X toolkit, cairo
version 1.15.10, Xaw scroll bars)
of 2022-07-15 built on phil-lp
Repository revision: 00eb894a56d63fad3573a53dd57c323289711512
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version
11.0.12008000
System Description: Ubuntu 18.04.6 LTS
Configured using:
'configure --prefix=/home/phil/emacs/trunk/usr/local
--with-x-toolkit=lucid --without-sound
'--program-transform-name=s/^ctags$/ctags_emacs/''
Configured features:
CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ JPEG JSON
LCMS2 LIBXML2 MODULES NOTIFY INOTIFY PDUMPER PNG RSVG SECCOMP THREADS
TIFF TOOLKIT_SCROLL_BARS WEBP X11 XDBE XIM XINPUT2 XPM LUCID ZLIB
Important settings:
value of $LC_MONETARY: en_NZ.UTF-8
value of $LC_NUMERIC: en_NZ.UTF-8
value of $LC_TIME: en_NZ.UTF-8
value of $LANG: en_GB.UTF-8
value of $XMODIFIERS: @im=ibus
locale-coding-system: utf-8-unix
Major mode: Lisp Interaction
Minor modes in effect:
savehist-mode: t
windmove-mode: t
winner-mode: t
tooltip-mode: t
global-eldoc-mode: t
eldoc-mode: t
show-paren-mode: t
electric-indent-mode: t
mouse-wheel-mode: t
tool-bar-mode: t
menu-bar-mode: t
file-name-shadow-mode: t
global-font-lock-mode: t
font-lock-mode: t
blink-cursor-mode: t
line-number-mode: t
indent-tabs-mode: t
transient-mark-mode: t
auto-composition-mode: t
auto-encryption-mode: t
auto-compression-mode: t
Load-path shadows:
None found.
Features:
(shadow sort mail-extr ibuffer ibuffer-loaddefs cl-extra thingatpt
shortdoc help-fns radix-tree help-mode emacsbug message mailcap
yank-media puny rfc822 mml mml-sec password-cache epa derived epg
rfc6068 epg-config gnus-util text-property-search time-date subr-x
mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils
mailheader sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr
mail-utils savehist windmove winner ring dired-aux cl-loaddefs cl-lib
dired dired-loaddefs advice rmc iso-transl tooltip eldoc paren electric
uniquify ediff-hook vc-hooks lisp-float-type elisp-mode mwheel
term/x-win x-win term/common-win x-dnd tool-bar dnd fontset image
regexp-opt fringe tabulated-list replace newcomment text-mode lisp-mode
prog-mode register page tab-bar menu-bar rfn-eshadow isearch easymenu
timer select scroll-bar mouse jit-lock font-lock syntax font-core
term/tty-colors frame minibuffer nadvice seq simple cl-generic
indonesian philippine cham georgian utf-8-lang misc-lang vietnamese
tibetan thai tai-viet lao korean japanese eucjp-ms cp51932 hebrew greek
romanian slovak czech european ethiopic indian cyrillic chinese
composite emoji-zwj charscript charprop case-table epa-hook
jka-cmpr-hook help abbrev obarray oclosure cl-preloaded button loaddefs
faces cus-face macroexp files window text-properties overlay sha1 md5
base64 format env code-pages mule custom widget keymap
hashtable-print-readable backquote threads dbusbind inotify lcms2
dynamic-setting system-font-setting font-render-setting cairo x-toolkit
xinput2 x multi-tty make-network-process emacs)
Memory information:
((conses 16 58167 33316)
(symbols 48 6207 0)
(strings 32 20424 1989)
(string-bytes 1 582261)
(vectors 16 11596)
(vector-slots 8 167080 10019)
(floats 8 74 16)
(intervals 56 488 2)
(buffers 992 16))
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#58218: 29.0.50; url-retrieve-synchronously with timeout causes process-query-on-exit
2022-10-01 10:55 bug#58218: 29.0.50; url-retrieve-synchronously with timeout causes process-query-on-exit Phil Sainty
@ 2022-10-01 11:44 ` Eli Zaretskii
2022-10-01 12:51 ` Phil Sainty
2022-10-01 12:33 ` Lars Ingebrigtsen
1 sibling, 1 reply; 6+ messages in thread
From: Eli Zaretskii @ 2022-10-01 11:44 UTC (permalink / raw)
To: Phil Sainty; +Cc: 58218
> Date: Sat, 01 Oct 2022 23:55:05 +1300
> From: Phil Sainty <psainty@orcon.net.nz>
>
> If you use the TIMEOUT argument to `url-retrieve-synchronously' and the
> response is not obtained within that duration, then the process created
> for that request causes query-on-exit behaviour. I can reproduce this
> in all the Emacs builds I have, including this 29.0.50 build.
>
>
> ;; With a short timeout causing the request to be aborted:
>
> (url-retrieve-synchronously "http://www.example.com" nil nil 0.01)
> nil
>
> M-x list-processes
> www.example.com -- open -- -- Main (network connection to
> www.example.com:80)
>
> C-x C-c
> Active processes exist; kill them and exit anyway? (yes or no)
>
>
>
> ;; With a long timeout (or a nil timeout):
>
> (url-retrieve-synchronously "http://www.example.com" nil nil 5)
> #<buffer *http www.example.com:80*>
>
> M-x list-processes
> www.example.com -- open -- -- Main (network connection to
> www.example.com:80)
>
> C-x C-c
> exits without any process-related prompt
>
>
>
> I'm not sure why the network connection remains open in either case, but
> regardless of that it seems as if process-query-on-exit-flag is set if
> the request times out, and cleared if it does not. The query-on-exit
> case seems to me like a bug, especially when there is no obvious way to
> obtain the process object and change the flag.
Maybe I'm missing something, but if url-retrieve-synchronously exits
with a timeout, isn't it expected that the process be still alive, and
therefore that Emacs will ask you about killing it?
Or are you saying that when url-retrieve-synchronously exits due to
timeout, it should kill the process?
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#58218: 29.0.50; url-retrieve-synchronously with timeout causes process-query-on-exit
2022-10-01 11:44 ` Eli Zaretskii
@ 2022-10-01 12:51 ` Phil Sainty
0 siblings, 0 replies; 6+ messages in thread
From: Phil Sainty @ 2022-10-01 12:51 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 58218
On 2022-10-02 00:44, Eli Zaretskii wrote:
> Maybe I'm missing something, but if url-retrieve-synchronously exits
> with a timeout, isn't it expected that the process be still alive, and
> therefore that Emacs will ask you about killing it?
Only (IMO) if you were to try to exit Emacs so quickly that the process
was still waiting for the URL response at that time.
I wasn't clear about that, but I was leaving ample time for the process
to receive a response before using C-x C-c (at least several seconds,
for
a request which was taking less than 1 second when no shorter timeout
was
set).
> Or are you saying that when url-retrieve-synchronously exits due to
> timeout, it should kill the process?
My bug report was only about the query-on-exit behaviour, but... killing
the process if it times out might a good idea -- or a good thing to be
able to specify optionally?
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#58218: 29.0.50; url-retrieve-synchronously with timeout causes process-query-on-exit
2022-10-01 10:55 bug#58218: 29.0.50; url-retrieve-synchronously with timeout causes process-query-on-exit Phil Sainty
2022-10-01 11:44 ` Eli Zaretskii
@ 2022-10-01 12:33 ` Lars Ingebrigtsen
2022-10-01 12:50 ` Lars Ingebrigtsen
1 sibling, 1 reply; 6+ messages in thread
From: Lars Ingebrigtsen @ 2022-10-01 12:33 UTC (permalink / raw)
To: Phil Sainty; +Cc: 58218
Phil Sainty <psainty@orcon.net.nz> writes:
> (url-retrieve-synchronously "http://www.example.com" nil nil 0.01)
> nil
>
> M-x list-processes
> www.example.com -- open -- -- Main (network connection to
> www.example.com:80)
>
> C-x C-c
> Active processes exist; kill them and exit anyway? (yes or no)
Yes, it seems to be an accounting error in the code around
`url-http-mark-connection-as-busy' -- that function is called too late,
and marks the connection as busy after we've already exited, and then it
never marks the connection as non-busy... Hm...
We never get to
http -> Marking connection as free: www.example.com:80 #<process www.example.com<1>>
because we never get the callback. Hm...
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2022-10-01 12:59 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2022-10-01 10:55 bug#58218: 29.0.50; url-retrieve-synchronously with timeout causes process-query-on-exit Phil Sainty
2022-10-01 11:44 ` Eli Zaretskii
2022-10-01 12:51 ` Phil Sainty
2022-10-01 12:33 ` Lars Ingebrigtsen
2022-10-01 12:50 ` Lars Ingebrigtsen
2022-10-01 12:59 ` Phil Sainty
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).